Web app testing with the OWASP web security testing guide

thexssrat

Information gathering

Search engine recon
- Google dorking/yahoo dorking/…
  - Site:target.com -www -xxx…
  - We work exclusively, not inclusively. This means we start at the base site:target.com and exclude results we viewed. This ensures we don’t miss things. We ALSO work inclusively, but it’s only after working exclusively
Webserver fingerprint
Source code investigations
Asset discovery
User emulation ( Keep MiTM proxy open for site map population )
Endpoint discovery
Enumerate any admin interfaces
Enumeration of errors and stack traces
Repository recon
- github dorking
Fingerprint the application
Map the application architecture
Map out integration points
Find
- Data flows
- Paths
- Race’s

Exploits

Login system

Test the JWT token
- Signature Verification
  - The none signing algorithm sometimes is accepted
  - Weak HMAC Keys
  - HMAC vs Public Key Confusion
  - https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens
Login bypass
- Directory brute force
- SQLi
- Session ID prediction
Username enumeration
Credentials transported over HTTP
Default credentials
Issues in the registration process
- Tokens sent over plaintext?
- DoS by entering too many characters
- Register a user with XSS attack vector in every input field, use for further testing
Weak password systems
Test password reset systems
- Add second email parameter with email of attacker
- Any tokens sent over HTTP
- Weak predictable tokens
- Is the user forced to reauthenticate
SessionID in URL
Logout should invalidate session tokens
Validate that a hard session timeout exists.
Weak lockout
Is there any alternative login system
- Oauth
- Mobile login
- Token login with weak tokens
Testing for session puzzling
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/08-Testing_for_Session_Puzzling
Session hijacking
- Request from attackers website to victims bank for example to login. The bank will possibly return session vars if bad config. This leads to attackers owning session vars now.
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/06-Session_Management_Testing/09-Testing_for_Session_Hijacking

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.

usr2r00t

Thanks a lot bro 👏🏼🙏🏼