-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathCSRF
110 lines (61 loc) · 5.48 KB
/
CSRF
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
In order for a CSRF attack to be possible:
- a relevant action: email change functionality
- cookie based session handling: session cookie
- no unpredictable request parameters
CSRF (token is valid till from existing from requst)
- CSRF vulnerability with no defenses
+ there is no csrf-token to validate, we can create csrf poc to create crafted html to send to intruders
- CSRF where token validation depends on request method
+ by default, with request body email and csrf token is exist, if we remove csrf token then send request, it will trigger error for csrf token..
+ change request method to GET from POST, then send the request and observe that email has been updated with csrf or without csrf token..
+ for csrf-poc to send victim of create crafted html..
- CSRF where token validation depends on token being present
+ remove the csrf token and see if application accept the Post requst.. if &csrf= is exist with token, valid token must provide.. or it will error..
+ change the request method from Post to Get..
+ for csrf-poc to send victim of create crafted html..
- CSRF where token is not tied to user session
+ first apply above two technique i.e remove csrf-token and change request method..
++ check if csrf token is tied to user session++
++ two account is required to test this, from first account capture the request, from another account capture the same requst and copy the token
and request the token with first account using following token.
[if token works for once, it would not would not work twice, require refresh for new token]
- CSRF where token is tied to non-session cookie
+ It uses tokens to try to prevent CSRF attacks, but they are not fully integrated into the sites session handling system.
+ We have two accounts on the application that we can use to help design your attack. [wiener:peter] | [carlos:montoya]
+ using Burp suite proxy history of email update. Send the request to Burp Repeater and observe that changing the session cookie logs you out,
but changing the csrfKey cookie merely results in the CSRF token being rejected. This suggests that the csrfKey cookie may not be strictly tied to the session..
+ Open a private/incognito browser window, log in to your other account, and send a fresh update email request into Burp Repeater.
observe that if you swap the csrfKey cookie and csrf parameter from the first account to the second account, the request is accepted.
+ back to original request, serach "Message", observe that no csrf protection is exist:
[Request] GET /?search=Message HTTP/1.1
[Respose] Set-Cookie: LastSearchTerm=Message; Secure; Http
+Modify the Request..
[Request] /?search=Message%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None
[Respose] Message Set-Cookie: csrfKey=KeY SameSite=None
+ add CSRF POC and send to victims:
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrfKey=YOUR-KEY%3b%20SameSite=None" onerror="document.forms[0].submit()">
- CSRF where token is duplicated in cookie:
+ Burp history, check "Email Update" request, send the request to repeater and observe that the value of the csrf body parameter is simply
being validated by comparing it with the csrf cookie. both must be same to accept the request.
+ perform a search and send the resulting request to repeater and observe that the search term gets reflected in the Set-Cookie header..
since the search function has no CSRF protection.. we can use this to inject cookies into the victim user browser..
+ create a URL that uses this vulnerability to inject a fake csrf cookie into the victim's browser:
[request] /?search=test%0d%0aSet-Cookie:%20csrf=Test%3b%20SameSite=None
+ CSRF PoC
<img src="https://YOUR-LAB-ID.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=fake%3b%20SameSite=None" onerror="document.forms[0].submit();"/>
-SameSite Lax bypass via method override
-SameSite Strict bypass via client-side redirect
-SameSite Strict bypass via sibling domain
-SameSite Lax bypass via cookie refresh
- CSRF where Referer validation depends on header being present:
+ this labs email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests but the detection mechanism can be bypassed.
+ check the brup proxy history and check the resulting request of "Update email" form.
- send the request to Burp Repeater. Observe that if you change the domain in the Referer HTTP header, the request is accepted.
- add this line of code under <head> tag of html -> <meta name="referrer" content="no-referrer">
- CSRF with broken Referer validation:
+ this labs email change functionality is vulnerable to CSRF. It attempts to detect and block cross domain requests but the detection mechanism can be bypassed.
+ check the brup proxy history and check the resulting request of "Update email" form.
-send the request to Burp Repeater. Observe that if you change the domain in the Referer HTTP header, the request is rejected.
+ with original request add "https://arbitrary-incorrect-domain.net?" before the original url request and send the request and observe it works and accepted.
-Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net
+ Create a CSRF POC. add this "history.pushState("", "", "/?YOUR-LAB-ID.web-security-academy.net")"