Web App Pentesting Checklist
Web App Pentesting Checklist
Exploits
Login system
Input validation
XSS
Reflected XSS
Stored XSS
Blind XSS
DOM XSS
SQLi
XXE
Command injection
SSTI/CSTI
Insert ${7*7} into every field you see, if it resolves, investigate further
SSRF
Add burp collaborator URL in everywhere that URL resolves
HTTP parameter polution
https://owasp.org/www-project-web-security-testing-guide/latest/4-
Web_Application_Security_Testing/07-Input_Validation_Testing/04-
Testing_for_HTTP_Parameter_Pollution
LDAP injection
SSI (server side includes injection)
XPath injection
Clickjacking
GraphQL testing
General exploits
RFI/LFI
Insecure session management
Subdomain takeover
Check if user role is user controllable (Can you make yourself admin)
Test the cookies attributes
Sensitive cookies should have secure and httponly flag
Domain and path need to be set right
Expires in timely manner
SameSite Attribute
CSRF testing
Only on sensitive functions, not on login/logout
File upload testing
Uploading of malicious content
File upload restrictions
Changing mimetype
Using nullbytes
Test integration points for overextended priviledges
Test if the browser caches sensitive information
Use the back button after logout timer
Click around after login timer
Check cache headers on sensitive pages
There should not be any weak encryption used anywhere
Search for the following keywords to identify use of weak algorithms: MD4,
MD5, RC4, RC2, DES, Blowfish, SHA-1, ECB
Business logic flaws
Data validation
example may be if I use my credit card at multiple locations very quickly
it may be possible to exceed my limit if the systems are basing decisions on last
night’s data.
Identify data injection points.
Validate that all checks are occurring on the back end and can’t be
bypassed.
Attempt to break the format of the expected data and analyze how the
application is handling it.
Test for hidden parameters that you can change with impact.
For example changing account type from consumer to business
Check for things that are only hidden in the front-end
Check for disabled fields that are only front-end disabled
Integrity checks
Review the project documentation for components of the system that move,
store, or handle data.
Determine what type of data is logically acceptable by the component and
what types the system should guard against.
Determine who should be allowed to modify or read that data in each
component.
Attempt to insert, update, or delete data values used by each component
that should not be allowed per the business logic workflow.
Test functions that can only be used a limited amount of times
For example a coupon code that you should only be applying one time but
that’s just a front-end check
If something gets added to account and should be withdrawn again, check if it
is.
For example if you order an item but cancel the order, your loyatee points
should go down as well.