Find subdomains, Ip blocks, email addresses, the harvester is a nice tool. I.e: python theHarvester.py -d example.org -n -c -t -b google
There is a nice collection of OSINT tools at http://osintframework.com/, feed the harvester results there and recurse.
Find services, Banners and versions. Research CVEs and exploit-db for those.
Find newest features, and forgotten endpoints at https://web-beta.archive.org
Check robots.txt crossdomain.xml and clientaccesspolicy.xml
$ dig guif.re <type> @22.214.171.124 # types: a, mx, ns, soa, srv, txt, axfr
$ dig -x guif.re # reverse lookup
Map their infrastructure: middleware, programming languages, backends, servies. This can help https://wappalyzer.com/
Find hidden folders, files. Nice list for fuzzing content discovery: https://c.darenet.org/nitemare/SecLists/tree/master/Discovery/Web_Content
$ dirb http://target wordlists/dirb/common.txt
$ nikto –host http://target
Spider/map all the functionalities of the application, discover hidden & default content, doing automateda and manual crawling.
Identify data entry points, technologies used. What does the application do? How does it do it? Map attack surface, dangerous functionalities, how they are implemented. Versions of the libraries, frameworks and known CVEs.
Check comments in source of all pages
Identify all parameters. Document which parameters are used for GET and POST
Identify where cookies are set, modified or added to.
Note any strange headers
$ ./whatweb guif.re # identifies all known services
$ dirb https://guif.re /usr/share/wordlists/dirb/common.txt # brutefor
Use Shodan for finding similar apps and endpoints, SSH hash keys
Find previous vulnerabilities of the web site. Recon-ng is a useful tool; use recon/domains-vulnerabilities/xssposed; set source example.org; run
RTFM - Read the manual for the application you are testing, does it have a dev mode? is there a DEBUG=TRUE flag that can be flipped to see more?
Look for where you can put data, is it an API? Is there a paywall or sign up ? Is it purely unauthenticated?
Look at the application from a bad guy perspective, what does it do? what is the most valuable part? Some applications will value things more than others, for example a premium website might be more concerned about users being able to bypass the pay wall than they are of say cross-site scripting.
Look at the application logic too, how is business conducted?
If testing a bug bounty, look for new aquisition, code from new team, new mobile apps versions, new UI in web, new functionalities.
Testing input validation
Append .old or .bak to files
Run automated scanning against web app, Burp, nikito and dirb.
Use wpscan to assess wordpress plugins
Use cmsmap for durpal and joomla known bugs
Flashbang to decode swf files, online tool
Script to request every https request to http
Find parameters being reflected.
Test for XSS
Test open redirection
Test header injection
Test parameter pollution
Test link manipulation
Test template injection.
Test server side issues (error-based, blind, outband, stored, different context(numeric, single and double quoted))
Test for SQL injection
Test for Server-side include
Test for OS command injection
Test for path traversal
Test for file inclusion - both local and remote
Test for SMTP injection
Test for SOAP injection - can you inject SOAP envelopes, or get the application to respond to SOAP, this ties into XXE attacks too.
Test for LDAP injection - not so common anymore but look for failure to sanitise input leading to possible information disclosure
Test for XPath injection - can you inject xml that is reflected back or causes the application to respond in a weird way?
Parsing of XML, JSON, or any other markup language that the application processes. Test for injection attacks, SSRF, xpath, XXE, insecure object de-references.
Look for parameters encoded in base64 or others, test again for injection attacks and insecure object de-references.
Test HTTP Options, use arbitrary method names to attempt to bypass authentication pages
Test any client side applet such as flash, activex and silverlight.
For file uploads functionalities, look for reflected file download.
Ensure anti-CSRF mitigations are in place for main functionalities and clickjacking mitigations.
If there is a binary, and runs as root, it should use https only and verify checksum or singed check with public key
File uploads. SVG can have embedded XML that triggers SSRF, XXE.
Check for DOM-based attacks - open redirection, cross site scripting, client side validation.
Check for frame injection, frame busting(can still be an issue)
Caching poisoning issues
Sensitive data in URL parameters
Follow up any information leakage
Check for weak SSL ciphers
Test CORs policy. if CORS or crosssdomain.xml allow subdomain, you can trick a user into doing XSS to that page by injecting an iframe to all web pages he visits to a subdomain i.e. sub.vulnerable.com, intercepting all requests for that host and returning html that will issue a cross domain request to vulnerable.es and display it to the UI.
Verify Content Security Policy (CSP)
Verify HTTP Strict Transport Security (HSTS)
Verify HTTP Public Key Pinning
Burp extension to see what users can see (authorization)
basic auth brute force : $ nmap -d -vv -p 80 --script http-brute --script-args http-brute.path=/ www.example.org
Password quality rules, length, character set allowed (alphanumeric, upper/lower case and special characters). Empty Password? Empty username? 123456?
Test username enumeration
Test account recovery functionality, look for SMTP header injection.
Does remember me expires?
Test removing your email address from your account, add a new one, make sure that the old one can not be used to recover password/log in.
Delete an account without entering password or other sensitive operations, in case you forgot your computer logged in.
Password bruteforcing resilience. Application locks after some attempts?
Rate limiting in change password functionalithy, forgot to log out in a cyber cafe, brute force the actual password using this feature. Does the application lock out an account after x number of login attempts?
Email verification links through http
Cookies: scope, httponly, secure flag.
Broken OAuth authentication, make sure ID tokens generated by google or third party are properly validated on the backend. https://developers.google.com/identity/sign-in/web/backend-auth#verify-the-integrity-of-the-id-token
Other strange access control methods such as referral validation (which can be bypassed https://t.co/z84ajd7bmO)
Does the remember me function ever expire? Is there room for exploit-ability in cookies combined with other attacks?
Test username uniqueness
How are logins processed, are they sent over http? Are details sent in a POST request or are they included in the URL(this is bad if they are, especially passwords)?
Test for fail-open conditions. Fail-open authentication is the situation when the user authentication fails but results in providing open access to authenticated and secure sections of the web application to the end user.
Testing session management
How well are sessions handled, is there a randomness to the session cookie? Are sessions killed in a reasonable time or do they last forever? Does the app allow multiple logins from the same user(is this significant to the app?).
Test tokens for meaning
What do the cookies mean?!
Test tokens for predictability
Are tokens generated predictable or do they provide a sufficiently random value, tools to help with this are Burp Suite's sequencer tool.
Check for insecure transmission of tokens
Check for disclosure of tokens in logs
Are tokens cached in browser logs? Are they cached server side? Can you view this? Can you pollute logs by setting custom tokens?
Check mapping of tokens to sessions
Is a token tied to a session, or can it be re-used across sessions?
Check session termination
is there a time-out?
Check for session fixation
Can an attacker hijack a user's session using the session token/cookie?
Check for cross-site request forgery
Can authenticated actions be performed within the context of the application from other websites?
Check cookie scope
Is the cookie scoped to the current domain or can it be stolen, what are the flags set> is it missing secure or http-only? This can be tested by trapping the request in burp and looking at the cookie.
Understand the access control requirements
How do you authenticate to the application, could there be any flaws here?
Test effectiveness of controls, using multiple accounts if possible
Test for insecure access control methods (request parameters, Referrer header, etc)
Weak cookie options
Session tokens strength
Test for session fixation.
Testing business logic
I do this step last, as it is when I am more familiar with the application and more likley to identify these issues.
Identify the logic attack surface
What does the application do, what is the most value, what would an attacker want to access?
Test transmission of data via the client
Is there a desktop application or mobile application, does the transferral of information vary between this and the web application
Test for reliance on client-side input validation
Does the application attempt to base it's logic on the client side, for example do forms have a maximum length client side that can be edited with the browser that are simply accepted as true?
Test any thick-client components (Java, ActiveX, Flash)
Does the application utilize something like Java, Flash, ActiveX or silverlight? can you download the applet and reverse engineer it?
Test multi-stage processes for logic flaws. Can you go from placing an order straight to delivery thus bypassing payment? or a similar process?