Pentesting_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)

"

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

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

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

2. enabling 2fa does not end another sessions

3. change password

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

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.