This document is a collection of practical tips and techniques gathered from various bug bounty write-ups. The goal is to share these real-world scenarios to get a better perspective on finding vulnerabilities and developing a hacker's mindset.

🔑 Authentication & Access Control Techniques

• Bypassing OTP with Null or True Values In processes requiring a One-Time Password (OTP), check if you can bypass the verification step by submitting a null or true value for the otp parameter in the request.
• Testing for Broken Access Control After Registration Create a new account. Before completing the full verification process (e.g., email confirmation), try to directly navigate to sensitive dashboard URLs that should require full access. Sometimes, access restrictions are not properly enforced.
• Fuzzing for Admin Parameters In requests you send to the server (especially for profile updates), manually add parameters like is_admin=true, role=admin, or account_type=1 to test for privilege escalation vulnerabilities.
• Testing Old Token Validity in Password Reset Request a password reset twice, which will generate two different tokens/links. Use the first link to change your password. Then, check if the second (older) link is still valid and can be used to reset the password again. A token should be invalidated after use or upon the creation of a new one.
• Testing for Improper Account Deletion & Username Availability After deleting an account, immediately try to register again with the exact same username. If the registration is successful, it often means the account was only "deactivated" instead of being fully purged, which can lead to logical flaws.
• CSRF in 2FA Enable/Disable Functionality Check if the process of enabling or disabling Two-Factor Authentication (2FA) is protected by an anti-CSRF token. If not, an attacker could potentially disable 2FA on a victim's account.
• Account Takeover (ATO) via Duplicate Parameter Pollution In a password reset flow, try sending the email parameter twice in the request body: once with the victim's email and once with your own (e.g., [email protected]&[email protected]). Some misconfigured backends may process the second parameter, sending the reset link to the attacker.
• Bypassing Email Verification Requirement Register a new account. Log out immediately without verifying the email address. Then, try to log back in with the same credentials. A secure system should not allow a login session for an unverified account.

🔄 Session Management Vulnerabilities

• Improper Session Invalidation After Password Change Log in to a single account on two different browsers simultaneously (e.g., Chrome and Firefox). In the first browser, change the account's password. Then, go back to the second browser, refresh the page, and see if your session is still active and if you can still perform actions.
• Testing for Non-expiring Old Passwords This interesting logic flaw was found even in major platforms like Cloudflare. Change your account's password multiple times in quick succession. Then, try to log in using the very first password you set. If the login is successful, you've found a critical bug.

🎭 Bypass & Evasion Techniques

• Bypassing Nginx/WAF with Double URL-Encoding In one notable case, a researcher dumped the PII of 4.5M users and earned a $20k bounty by bypassing a filter.
  • A request to /get_all_users returned 403 Forbidden.
  • A request to /get_all_userz returned 404 Not Found (indicating the path was correct but filtered).
  • The researcher bypassed the filter by double URL-encoding the letter "s": Final Path: /get_all_user%2573
  • This technique was shared by bug bounty hunter Justin Gardner (Rhyno Raider) in a talk at DEF CON 32.
• Bypassing Username Restrictions with Spaces When trying to register a sensitive username like admin, you'll likely get a "username taken" error. Test the server's input trimming by adding spaces:
  • admin
  • admin
  • admin Sometimes, the server fails to sanitize the input and accepts it as a new, valid username.
• Finding Open Redirects with the Double Slash (//) Technique To test for Open Redirect vulnerabilities, try using a double slash after the domain name, which can sometimes bypass weak regex filters.
  • Example: https://targetdomain.com//bing.com