Loading...
This site is best viewed in a modern browser with JavaScript enabled.
Something went wrong while trying to load the full version of this site. Try hard-refreshing this page to fix the error.
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 👏🏼🙏🏼