forked from guifre/notes
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathwebpentest.txt
186 lines (168 loc) · 14.1 KB
/
webpentest.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
*Web penetration testing*
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|[email protected], then you can get a valid SSL certificate in https://help.comodo.com/topic-437-1-843-10844-.html or others.