Pentesting_Checklist
Register & Signup
2FA
check 000000 - 123456
check null
reuse previous OTP (used one )
reuse code of another account (valid)
No rate limit on 2FA =>>
check if exposed code in response
bypass 2FA by reset password link
enable 2fa
- logout
reset password => then click on the link
if you got into directly then vulnerability
bypass it by 0-auth google => 2fa 1. login 2. enable 2fa 3. login with google => if you got into directly then (vulnerability)
No rate limit on sending 2FA
response manipulation=>
403 Forbidden => 200 OK
false => true
0 => 1
failed => successful
bypass 2fa by the next step
enable 2fa without email verification lead to pre-account takeover
enabling 2fa does not end another sessions
change password
Login Pages
login over http not https ( insecure data transfer )
no rate limit over password
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)
try to inject sql injection in username as admin' or 1=1;-- -
try to make response manipulation to bypass login page
use the request and send it to sqlmap to test if there is sql injection or not
try to inject xss payloads in username as <svg/onload=confirm()>
try to inject template injection inside username as {{9*9}} and if printed 81 then vulnerable to template injection
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):
The attacker creates a new account using the victim’s email address (e.g., test@gmail.com).
No email verification is required, allowing the attacker to proceed.
The victim logs using the “Sign in with Google” option, selecting the same email (test@gmail.com).
Both the attacker and victim now have access to the same account.
The attacker monitors the shared account and gains access to all updates and data added by the victim (e.g., purchases, saved data).
The attacker adds their own email address as a secondary email and sets it as the primary email in account settings.
The attacker deletes the original email (test@gmail.com) from the account.
The system prompts for a new email; the attacker enters a random email and completes the process.
Outcome: The victim is permanently locked out of their account. If they attempt to log in using Google, a new account is created instead.
Last updated
Was this helpful?