Functionality Wise Checklist

A curated and comprehensive functionality wise checklist for Web Application Penetration Testing.

Login Functionality

  • SQL Injection

  • Insufficient Anti-Automation (Rate-Limiting Bypass)

    • IP-based restriction bypass using X-Forwarded-For header - Huntr.dev Report

    • IP-based Restriction bypass by rotating IP address - IP Rotate

    • Session-based restriction - Send request without the cookie.

    • Improper Captcha Implementation

    • In JSON, Padding \n after the e-mail - HackerOne Report

  • 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

Sessions

  • Old Sessions are valid after password reset

Missing Best Practice

  • Users not notified about the password change

Misc

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.

  • 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

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?

PreviousRecon ChecklistNextTechnology / Standard Wise Checklist

Last updated