Pentesting_Methodlogy&Checklist

Register & Signup

1- http not https  
2- No confirmation code lead to make account with admin email  
3- Confirmation link can be used multiple times to access account  
4- If OTP is send check rate limit  
5- Intercept the request and check if OTP is leaked in response  
6- try to create account , don't confirm it , go to settings and enable  
two factor authentication 2fa => pre-account takeover  
7- try to create account , don't confirm it , try to tie it with google or facebook , lead to pre-account takeover  
8- 0-auth senario  
- attacker creates account with [[e-mail]](mailto:[e-mail]) , can't verify it  
- victim registers account but with google 0-auth  
- now attacker account has been verified (verification bypass)  
  
9- bypass verification  
- create accont with [[e-mail]](mailto:[e-mail]) , you can't verify it  
- login and visit settings  
- change account with [[e-mail]](mailto:[e-mail]) => click on the link on your inbox  
- observe [[e-mail]](mailto:[e-mail]) has been verified successfully  
10- Delete account without password Confirmation  
11- xss via username , name as username='"><u>ahmedelhawary  
or "><svg/onload​=confirm(document.cookie)>"@x.y  
or [[e-mail]](mailto:[e-mail])'\"><svg/onload​=confirm(1)>  
or ">\<img src=[[https://lnkd.in/eqyaDP5b](https://lnkd.in/eqyaDP5b)
"

Login Pages

1. login over http not https ( insecure data transfer )

2. no rate limit over password

3. try default credentials (test:test) (admin:admin) (admin:password) (kali:kali) (admin:123)

4. (admin:default) (root:root) (root:toor) (admin:kali) (kali:root) (admin:123456789)

5. try to inject sql injection in username as admin' or 1=1;-- -

6. try to make response manipulation to bypass login page

7. use the request and send it to sqlmap to test if there is sql injection or not

8. try to inject xss payloads in username as <svg/onload​=confirm()>

9. try to inject template injection inside username as {{9*9}} and if printed 81 then vulnerable to template injection

10. view source code of the page from CTRL+U to see if leaked credentials

1- login over http not https ( insecure data transfer )  
  
2- no rate limit over password  
  
3- try default credentials (test:test) (admin:admin) (admin:password) (kali:kali) (admin:123)  
(admin:default) (root:root) (root:toor) (admin:kali) (kali:root) (admin:123456789)  
  
4- try to inject sql injection in username as admin' or 1=1;-- -  
  
5- try to make response manipulation to bypass login page  
  
6- use the request and send it to sqlmap to test if there is sql injection or not  
  
7- try to inject xss payloads in username as <svg/onload​=confirm()>  
  
8- try to inject template injection inside username as {{9*9}} and if printed 81 then vulnerable to template injection  
  
9- view source code of the page from CTRL+U to see if leaked credentials

2FA

1. check 000000 - 123456

2. check null

3. reuse previous OTP (used one )

4. reuse code of another account (valid)

5. No rate limit on 2FA =>>

6. check if exposed code in response

7. bypass 2FA by reset password link

   1. enable 2fa

   2. - logout

   3. reset password => then click on the link

   4. if you got into directly then vulnerability

8. bypass it by 0-auth google => 2fa

   1. login

   2. enable 2fa

   3. login with google => if you got into directly then (vulnerability)

9. No rate limit on sending 2FA

10. response manipulation=>

    1. 403 Forbidden => 200 OK

    2. false => true

    3. 0 => 1

    4. failed => successful

11. bypass 2fa by the next step

12. enable 2fa without email verification lead to pre-account takeover

13. enabling 2fa does not end another sessions change password

14. No CSRF protection on disabling 2FA, also there is no auth confirmation.

15. 2FA gets disabled on password change/email change.

16. Clickjacking on 2FA disabling page, by iframing the 2FA Disabling page and lure the victim to disable the 2FA.

17. Enabling 2FA doesn't expire previously active sessions, if the session is already hijacked and there is a session timeout vuln.

18. 2FA code reusability, same code can be reused.

1- check 000000 - 123456  
2- check null  
3- reuse previous OTP (used one )  
4- reuse code of another account (valid)  
5- No rate limit on 2FA =>>  
6- check if exposed code in response  
7- bypass it by reset password link  
- enable 2fa  
- logout  
- reset password => then click on the link  
- if you got into directly then vulnerability  
  
8- bypass it by 0-auth google => 2fa  
1- login  
2- enable 2fa  
3- login with google => if you got into directly then (vulnerability)  
  
9- No rate limit on sending 2FA  
10- response manipulation => 403 Forbidden => 200 OK  
false => true  
0 => 1  
failed => successful  
11- bypass 2fa by the next step  
  
12- enable 2fa without email verification lead to pre-account takeover  
13- enabling 2fa does not end another sessions  
change password

OAuth

OAuth Misconfig Leading to Pre-Account Takeover

Steps to Reproduce (POC):

1. The attacker creates a new account using the victim’s email address (e.g., [e-mail]).

   • No email verification is required, allowing the attacker to proceed.

2. The victim logs using the “Sign in with Google” option, selecting the same email ([e-mail]).

   • Both the attacker and victim now have access to the same account.

3. The attacker monitors the shared account and gains access to all updates and data added by the victim (e.g., purchases, saved data).

4. The attacker adds their own email address as a secondary email and sets it as the primary email in account settings.

5. The attacker deletes the original email ([e-mail]) from the account.

6. The attacker disconnects the Google authentication from the account by navigating to https://www.target.com/Settings-cpf and selecting “Disconnect” under Google Settings.

   • The system prompts for a new email; the attacker enters a random email and completes the process.

7. Outcome: The victim is permanently locked out of their account. If they attempt to log in using Google, a new account is created instead.

Replay OAuth attack

• Log in via Facebook OAuth, capture request with code parameter.

• Log out from the target application but remain logged into the OAuth provider. Attempt to log in again and check if re-authentication is required.

• Log out from app and Facebook, click "Login with Facebook" to test unauthorized access.

• Change Facebook password, attempt login to check if old code is accepted.

• Replay captured code in a new browser within 5 minutes to test reuse.

• Document requests, timestamps, and screenshots for report.

403 Forbidden Bypass

1. Using "X-Original-URL" header

GET /admin HTTP/1.1
Host: target.com

Try this to bypass

GET /anything HTTP/1.1
Host: target.com
X-Original-URL: /admin

1. Appending %2e after the first slash

http://target.com/admin => 403

Try this to bypass

http://target.com/%2e/admin => 200

1. Try add dot (.) slash (/) and semicolon (;) in the URL

http://target.com/admin => 403

Try this to bypass

http://target.com/secret/. => 200
http://target.com//secret// => 200
http://target.com/./secret/.. => 200
http://target.com/;/secret => 200
http://target.com/.;/secret => 200
http://target.com//;//secret => 200

1. Add "..;/" after the directory name

http://target.com/admin

Try this to bypass

http://target.com/admin..;/

1. Try to uppercase the alphabet in the url

http://target.com/admin

Try this to bypass

http://target.com/aDmIN

1. Via Web Cache Poisoning

GET /anything HTTP/1.1
Host: victim.com
X­-Original-­URL: /admin

Payment Manipulation Vulnerabilities

• Enter an incorrect discount code during a transaction.

• Intercept the HTTP request and response using a proxy tool (e.g., Burp Suite).

• Modify all amount values in the response to 0.

• Send the modified response back to the client to attempt transaction completion.

• Cart Item Manipulation: Modify the quantity or price of items in the cart (e.g., set quantity=-1 or price=0) via intercepted requests to lower or nullify the total amount.