3264
Talk and help about bugbounty
Please any idear I have found a bug on an application
Otp bypass no rate limit on the website but there is time limit if 2 minute
And that is not enough to Bruce force 6 digit Otp
🔍 Join the 30-Day Bug Hunting Challenge! 🌟💻
🔗 LinkedIn Post: https://lnkd.in/dANn3B97
Ready to join the hunt? 🕵️♂️💻 Don't miss this opportunity to showcase your expertise, earn rewards, and contribute to a more secure digital landscape!
📅 Starting Date: July 20, 2023
📆 Duration: 30 days
🌟 Why Join? 🌟
✅ Sharpen your bug hunting abilities.
✅ Make a real impact by improving digital security.
✅ Connect with like-minded bug hunters.
✅ Boost your professional portfolio.
Rules after join challange daily repost 1 bug any platform any program and attached screen short repost
But another thing that can happen if the cookies just never change, like for example in a login page, it might just not go anywhere. Might just loop
Читать полностью…
The exact stages of the attack and its difficulty depend on several factors. For example, a lot depends on how the application handles session IDs. If the application accepts session IDs from the URL (via a GET request), the attack is trivial. If the application accepts session IDs from POST requests, the attacker may need to create a fake phishing site. It gets more difficult (but not impossible) if session IDs are only accepted from cookies – the attacker must then use techniques such as Cross-site Scripting (XSS).
Читать полностью…
Again, an example would be session hijacking. Plus, a cookie session will essentially live throughout the lifetime the person is on the page/ browser.
Читать полностью…
Form that what type of impact will face to client
Читать полностью…
does any one have live bugbounty hunting resourses
Читать полностью…
What was the impact if the pre cookie and post cookie will be the same
Читать полностью…
Introducing SubScanX - Your Ultimate Subdomain Scanner!
🔎 Discover Responsive Subdomains with Ease! 🔍
📢 Exciting News! We are thrilled to introduce SubScanX - a powerful Python-based tool designed to simplify subdomain scanning and enhance your cybersecurity toolkit.
🚀 Key Features:
✅ User-Friendly Interface - GUI and Command Line modes for all skill levels.
✅ Swift and Reliable Scanning - Minimize false positives and get results in no time.
✅ Customizable Parameters - Fine-tune the scanning process as per your needs.
✅ Automated HTML Reporting - Access detailed reports with hyperlinked results.
✅ Real-time Progress Tracking - Stay informed about scan completion progress.
🌐 How to Use:
1️⃣ Clone the SubScanX repository from GitHub.
2️⃣ Install dependencies and run SubScanX in GUI or Command Line mode.
3️⃣ Load a list of subdomains and initiate the scanning process.
4️⃣ Review detailed HTML reports for responsive subdomains.
⚡️ Empower your security assessments, validate DNS configurations, and strengthen your web applications with SubScanX. It's a must-have tool for every security enthusiast! ⚡️
🎯 Download SubScanX from GitHub
🙏 Share the love! Spread the word about SubScanX and help others bolster their cybersecurity defense. Let's make the web a safer place together! 🙌
#SubScanX #Cybersecurity #SubdomainScanner #OpenSource #GitHub #InfoSec #WebSecurity #EthicalHacking
🔗 https://github.com/Aniruddhpathak404/SubScanX
write a script to brute force it with high threads
Читать полностью…
Everyone request this post so that everyone's post can reach
Читать полностью…
If the app is vulnerable against such vectors (injection, xss, whatever), then it has to be fixed and the way how an attacker get the session-id doesn't really matter. It is simply secondary and what you try to achieve with "hidding the session-id" is calling security through obscurity. Both things are basically orthogonal, and although it is advisable to use safe and periodically expiring session-id, the reasons for that are mostly different, and closing all the vulni-vectors (like inject, xss, etc) are definitely more important than a session hijacking, because can be used without the session (or with known safe and short living session-id).
With other words it doesn't matter whether you'd regularly change the oil in a car with broken engine - better would be to repair the engine firstly.
But I see it more possible of a vulnerability because let’s say you login and logout and the session ID is the same. Would be a lot easier to hijack your session once you sign back in because it’ll always be the same
Читать полностью…
Essentially. There’s a couple of ways to hijack a session or session ID
Читать полностью…
The attacker accesses the web application login page and receives a session identifier generated by the web application. This step is not necessary if the web application accepts arbitrary session IDs.
The attacker uses an additional technique such as CRLF Injection, man-in-the-middle attack, social engineering, etc., and gets the victim to use the provided session identifier. This depends on how the web application handles session IDs. It may be as simple as sending a malicious URL but may also require the attacker to create a fake website.
The victim accesses the web application login page and logs in to the application. After authenticating, the web application treats anyone who uses this session ID as if they were this user.
The attacker uses the session identifier to access the web application, take over the user session, and impersonate the victim. Further actions depend on the attacker and web application functionality.
If the pre session cookie and the post session cookie will the same what will happen
Читать полностью…
Do you have an example of what you’re trying to achieve? I mean i don’t really see a potential risk “if” get and post are the same. Unless someone is trying to hijack a session
Читать полностью…
Not understanding your question well. What would happen in what sense?
Читать полностью…
What will happen when pre cookie and post cookie will the same
Читать полностью…