# Functionality Wise Checklist

### Login Functionality

* SQL Injection
* Insufficient Anti-Automation (Rate-Limiting Bypass)
  * IP-based restriction bypass using X-Forwarded-For header - [Huntr.dev Report](https://huntr.dev/bounties/a9595eda-a5e0-4717-8d64-b445ef83f452/)
  * IP-based Restriction bypass by rotating IP address - [IP Rotate](https://portswigger.net/bappstore/2eb2b1cb1cf34cc79cda36f0f9019874)
  * Session-based restriction - Send request without the cookie.&#x20;
  * Improper Captcha Implementation
  * In JSON, Padding \n after the e-mail - [HackerOne Report](https://hackerone.com/reports/1040471)
* Username enumeration
  * Based on error
  * Based on the response time difference for valid/invalid user
* XSS, If the username is reflected in the response
* Open Redirection, using the return\_to parameter during login
* Remember me checkbox Improper Implementation, Check for user-related contents within the cookie, html5 storage.
* Default Credentials

### Forgot Password

**Password Reset Token**

* Token length, Complexity, and Entropy
* Token Generation Logic: Timestamp, User ID, Email of the user
* Token Leakage in response
* Token generated for one user can be used for another user
* Empty value accepted for the token parameter
* Token value 000000000000 is accepted
* NULL Token value is accepted
* Same token can be used more than once
* Token doesn't have an absolute expiry
* No rate-limiting for the tokens
* Change 1 char at the beginning/end of the token to see if it is validated
* Password token leaked in referrer header to the links in the password reset page when clicked (Cross-Domain Referrer leakage)

**Email Address**

* Multiple Emails in the same parameter using separators (, | %20). (Ex: email=<victim@gmail.com>,<attacker@gmail.com>)
* Parameter Pollution - Including another email parameter in the request. Sometimes, the password reset email might be sent to both emails (Ex: email=<victim@gmail.com>\&email=<attacker@gmail.com>)
* Adding another element In JSON array. Example: {"email":\["<victim@mail.tld>","<attacker@mail.tld>"]}
* CRLF to add CC - Example: email="<victim@mail.tld>%0a%0dcc:<attacker@mail.tld>"

**Host Header**

* Host Header Injection - Inject host header with a different domain while requesting, the link sent to the user might have the injected domain name - [HackerOne Report](https://hackerone.com/reports/226659)

**Sessions**

* Old Sessions are valid after password reset

**Missing Best Practice**

* Users not notified about the password change

**Misc**

* Get Parameter Taking precedence over post - [HackerOne Report](https://hackerone.com/reports/96636)

**References**

* <https://twitter.com/HusseiN98D/status/1254888748216655872/photo/1>
* <https://anugrahsr.github.io/posts/10-Password-reset-flaws/>
* <https://cheatsheetseries.owasp.org/cheatsheets/Forgot\\_Password\\_Cheat\\_Sheet.html>

### Registration

* Look for parameters like user\_type and try changing it to different roles.
* XSS in name or other reflected parameters
* SQL Injection
* Missing Captcha
* Password complexity not enforced
* Lack of verification of emails/mobile numbers
* Registering with one email with proper verification but after logging in changing to another email without verification.
* Registering an existing email address overwrites the current password

### 2FA

**Response Manipulation**

* Change status codes from 401, 402 to 200 OK
* Change response body from false to true
* Prior to sending OTP, if there is a response containing 2FA\_enabled:true change it to false

**Insecure Disable OTP Functionality**

* Clickjacking on the disable button
* CSRF on the disable OTP page
* No 2FA to disable 2FA

**OTP Leakage**

* OTP is being leaked in request/response
* OTP is determined in the JS files
* OTP is Based on Timestamp. (Send OTP from a different user at the same time to verify)

**Token validity**

* OTP can be used more than once
* Multiple codes are active for a single user at a given time. (Request multiple OTPs and try to brute-force)
* OTP validity duration
* OTP of one user can be used for a different user

**Parameter Tampering**

* The mobile number to which the OTP is sent to present in the request and can be modified

**Forced Browsing**

* Directly access the page that comes after the 2FA, or any other screens that come after 2FA
* Directly access the page that comes after the 2FA and set the referred header as the 2FA page

**Rate-Limiting**

* Lack of rate-limiting in OTP validation leading to brute force
* Lack of rate-limiting in OTP initiation leading to OTP flooding

### File Upload

**File Type Restriction**

* If the file type validation is implemented only on the client side, change it to the malicious extension during burp intercept.
* If the file type restriction is only based on the content-type header
  * Change the content type to an accepted content-type.
  * Send an empty content-type
  * Try using the Content-Type twice with the accepted content-type and restricted content-type.
* If the file type is validated based on the magic byte, change the magic byte to an accepted file type.
* If the file type is validated based on the file extension, check if the validation is on a black list or a white list of extensions.

**File Extension Restriction Bypass**

* Modify the casing of the extension. For eg: .pHp, .AsPx
* Use of Null bytes, Unicode characters and special characters in the end of the extension. For eg: file.php%0a, file.php%00, file.php%0d%0a.
* Use double extension. For eg., if .txt is a supported extension try .txt.php
* Use double extension in combination with Null bytes, Unicode and special characters. For eg: file.php%00.png, file.php\x00.png, file.php%0a.png, file.php%0d%0a.png
* Extremely long file name with double extension, where the supported extension gets cut off when creating file. For eg: AAAAA<-SNIP->AAAAA.php.txt.
* Add . at the end of the extension. For eg. webshell.aspx.
* Use empty extension. For eg: test.
* Use empty file name. For eg: .php
* Send the filename twice within request with allowed and disallowed extensions, For eg. filename="file.png";filename="file.svg"

**Extensions**

* Remote Code Execution. Upload the server-side script based on the application's development language
  * PHP - .php, .php4, .php5, .phtml, .module, .inc, .hphp, .ctp
  * ASPX - .asp, .aspx, .shtml, .ashx, .asmx.
* Remote Code Execution. Upload configuration file based on the web server
  * Apache - .htaccess
  * IIS - web.config
* Cross Site Scripting. Upload .html, .svg files to perform remote code execution.

**File Name - Input Validation**

* XSS - Upload a file with the name containing xss payload. e.g.&#x20;
* SQLi - Upload a file with the name containing xss payload. e.g. sleep(10)-- -.jpg
* Path Traversal - Upload a file with the name containing path traversal payload. e.g. ../../../../../../etc/passwd
* Command Injection - Upload a file name with command injection payload. e.g. ; sleep 10;

**Image Validation Bypass**

* Image Compression using PHP-GD - [PLTE chunk](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)
* Image Resizing using PHP-GD - [IDAT chunk](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)
* Image Resizing using Imagick - [tEXt chunk](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html)

**Storage Exhaustion**

* Check the maximum file size accepted.
* Check if there is rate-limiting for the file upload.

**Missing Best Practice**

* The file upload URL is disclosed after the file is uploaded.
* The file is uploaded within the web root.
* User-supplied file name is not changed to a different name when the file is created on the server.

**References**

* <https://book.hacktricks.xyz/pentesting-web/file-upload>
* <https://www.onsecurity.io/blog/file-upload-checklist/>
* <https://0xn3va.gitbook.io/cheat-sheets/web-application/file-upload-vulnerabilities>

### Promo Code / Coupon

* Can the code be used more than once?
* Is the code predictable?
* Is there rate-limiting in the code redeeem functionality?
* Is there a race condition vulnerability in the redeem functionality?


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://hak2learn.gitbook.io/hak2learn/webapp/checklist1.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
