Web penetration testing

Web penetration testing ToC

Reconnaissance
Testing input validation
Server issues
Testing authentication
Testing session management
Testing business logic
Cache attacks
Others
OAuth2
DNS Rebinding
Cross domain requests
Others

Reconnaissance

Map the attack surface
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
Find hosts:

$ dig guif.re a; @8.8.8.8 # types: a, mx, ns, soa, srv, txt, axfr

$ dig -x guif.re # reverse lookup

Google site: to find information leakage
Map their infrastructure: middleware, programming languages, backends, services. 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.
Read the client code of the web app, what javascript libraries it use, code looks messy?, sinks, etc
Check comments in source of all pages
Generate an error page, sometimes vulnerable to XSS.
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 # bruteforce

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 acquisition, code from new team, new mobile apps versions, new UI in web, new features.

Testing input validation

Append .old or .bak to files
Run automated scanning against web app, Burp, nikto and dirb.
Use wpscan to assess wordpress plugins
Use cmsmap for durpal and joomla known bugs
Flashbang to decode swf files, online tool
Find parameters being reflected and test for: XSS, HPP, link manipulation, template injection.
Test server side issues (error-based, blind, outband, stored, different context(numeric, single and double quoted)) such as: SQL injection, Server-side include, OS command injection, path traversal, file inclusion both local and remote, SMTP injection, SOAP injection get the application to respond to SOAP, this ties into XXE attacks too. LDAP injection, XPath injection, code injection, deserialization attacks, overflow attacks.
A parameter looks like a file? Test path traversal, RFI, LFI
A parameter looks like a URL? Test open redirection SSRF
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.
Check for DOM-based attacks - open redirection, cross site scripting, client side validation.
File uploads. SVG can have embedded XML that triggers SSRF, XXE.
If user has profile and avatar, upload a malicious SVG with script.

Server issues

Script to request every https request to http
Test header injection
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. Uploading files with double extensions (.php5.jpeg) and using a null byte (.php5%00.jpeg)
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
Captcha bypassing
Check for frame injection, frame busting(can still be an issue)
Caching poisoning issues
Sensitive data in URL parameters
Follow up any information leakage
Look at numeric IDs, they can tell you much many orders, users etc. Looked for hashed numeric ids
Look swf they are always vulnerable
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). Look for bypasses
Verify HTTP Strict Transport Security (HSTS)
Verify X-XSS-Protection
Verify X-Content-Type-Options
Verify HTTP Public Key Pinning

Testing authentication

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 functionality, 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 NULL %00 characters in the username and password fields.
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.
Cookie poisoning. Try requesting the cookie names in the query string and body, some servers might read the parameters and set them as cookies. This can allow cookie poisoning.
Set new password with old password

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
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 Can they be accessed by JavaScript? Is this an Issue?
Check for disclosure of tokens in 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
Check for session fixation
Can an attacker hijack a user's session using the session token/cookie?
Check for XSRF
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)
Persistent cookies
Session tokens strength
Authorization properly enforced

Testing business logic

I do this step last, as it is when I am more familiar with the application and more likely 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 protocols used 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?

Cache attacks

Poisoning (if only path is validated you can submit malicious queries/headers) and cache bad results
Race conditions: buy twice, get someone else's data
If header injection: Inject a new response, the cache might store the attacker-controllable one
Using multiple host headers or X-Forwarded-Host might cause the cache to load the attacker's site and serve it. Or the links to be written relative to the attackers host.
Dns cache poisoning: The attacker creates a fake response to the DNS server that is cached, all users will get the wrong response until TTL.
Side-channel attacks They exploit timing/energy consumption/noises/electromagnetic leaks rather than a direct weakness in the system.
Offline Web Application Cache Poisoning The attacker loads an iframe of victim who uses wifi. The iframe points to facebook.com but caches the phising site for a few days. When the user logs in at home it opens the cached poisoned site.

Others

Testing wordpress sites

$ wpscan -url http://$ip/ -enumerate p

Quick wordpress bruteforce:

$ python patator.py http_fuzz url=http://$ip/wp-login.php  raw_request=rawlogin 0=/usr/share/rockyou.txt -l /tmp/login &; tail -f /tmp/login | grep 302

Fingerprint application

$ ./clusterd.py --fingerprint  -i $ip
BlindElephant.py $ip

Request site with specific cipher

$ curl --ciphers ECDHE-RSA-AES256-SHA https://$ip

Deobfuscate JS

JStillery, JSNice

OAuth2

Allows a server to authenticate a user without any password. The app uses a service provider to authenticate users.
Authentication flow:

User clicks login with facebook.

User gets redirected to Facebook facebook.com/oauth?redirect_uri=target.com%2fcallback&state=xyz

If the login is successful, he will be redirected to target.com

browser makes a request to including the state value

Client should validate the state value to prevent csrf.

Pitfalls:

CSRF: use the redirect URL that contains the authorization code and make a victim visit it

Open redir: attacker constructs and authorization request URL for provider site with redirect_uri set to attacker.com, when user gets redirected attacker can read authorization code in the referrer

Access token re-use: evil consumer site can authorize victim in provider site using access token, attacker uses the token to impersonate

DNS Rebinding

Attacker controls the authoritative nameserver for attacker.com
User visits attacker.com
NS responds with A record with the attacker.com IP, and short TTL
The browser fetches a resource, i.e. /secrets
The DNS response has expired, now the DNS server responds with victim.com IP.
The browser will fetch victim.com/secrets in the attacker.com origin.
Attacker can return a CNAME entry to bruteforce internal hostnames

Cross domain requests

Browser will do GET requests and POST that has standard content-type
Otherwise, the browser will do an OPTIONS request and check the CORS headers

Others

If you can register an email like admin|administrator|hostmaster|postmaster|webmaster@subdomain.victim.com, then you can get a valid SSL certificate in https://help.comodo.com/topic-437-1-843-10844-.html or others.