➡ Use intruder to send many reset links/token to your email in a short amount of time and compare the links/tokens.
If only a few digits are different you can brute force them. After you can do the same with 2 different emails
➡ HTTP Parameter Pollution
When requesting a password reset link:
email=victim@domain.com&youremail@domain.com
When resetting password:
token={token}&email=youremail@domain.com&email=victim@domain.com
➡ If you find your password reflected in response/source code don't report it yet
Check if it is vulnerable to CORS or any IDOR to steal other user's passwords
➡ Check if any CSRF token is implemented while changing profile information, if not generate CSRF PoC while changing email
➡ Link your account to facebook/google and capture the request, if there is no CSRF here you can send the link to a victim to link your google to his account, then you log in using google
➡ (Once got that)
While linking account to facebook, POST request looked like : oauth={token}&userid=myuserid&email=myemail
• If you're testing for XSS on a site with a CSP, use burp's find+replace on the CSP reporting uri to point to a burp collaborator instance so you don't have to monitor dev tools for csp exceptions.
🧵:👇
• Search for hidden (and visible) input fields and try to set the value via GET. A lot of Webapps still use $_REQUEST. You will be surprised. If you have a
reflected value -> check of html/script injection.
• Now, if you are slightly experienced, after a few minutes of tinkering with this workflow, you will get a feeling whether it might have something interesting going on or not. This point is difficult to explain. It will come with practice.
🧵:👇
• The weird behavior doesn’t necessarily mean you have found a bug that is worth reporting. It probably means you have a good chance so you should keep digging into it more.
☑ Establish how session management is handled in the application (eg, tokens in cookies, token in URL)
☑ Check session tokens for cookie flags (httpOnly and secure)
☑ Check session cookie scope (path and domain)
Thread🧵(1/n) :👇
☑ Check session cookie duration (expires and max-age)
☑ Check session termination after a maximum lifetime
☑ Check session termination after relative timeout
☑ Check session termination after logout
☑ Test to see if users can have multiple simultaneous sessions
🧵(2/n) :👇
☑ Test session cookies for randomness
☑ Confirm that new session tokens are issued on login, role change and logout
☑ Test for consistent session management across applications with shared session management
☑ Test for session puzzling
☑ Test for CSRF and clickjacking