Cross-site request forgery (CSRF) is an attack that involves phishing a victim to visit a malicious site. The malicious site proceeds to execute actions on the victim’s behalf, commonly involving the reuse of a victim’s cookies or authenticated session with a target site to submit forms, read privileged content, etc. The official definition for this attack is provided by OWASP:
SameSite cookies
A mitigation for CSRF attacks is to disable the browser’s usage of cookies when
making cross-site requests. When a server offers a browser a cookie, it can set
the
SameSite
attribute, setting it to Lax, Strict, or None. With Laxand Strict, it
becomes difficult for an attacker to coerce a victim’s browser to provide a
cookie for requests against a target site.
Here’s a great tool to determine what browsers use the SameSite attribute:
CSRF tokens
CSRF tokens are managed by the server, and usually embedded into the HTML of a
document, hidden, and tied to a form. The server expects the user to provide
both the form content, and the CSRF token when submitting a POST request. If a
CSRF token is not provided, the server will reject the POST request,
regardless of its content.
This mitigation makes it difficult for attackers to submit POST requests on a
victim’s behalf, even if they can coerce the victim’s browser to submit a
session cookie for authentication. Without the contents of a CSRF token provided
by the server, tied to the current session, attacker-generated requests will be
denied by the server. More on CSRF tokens below:
Weak CORS policies
Keep an eye out for servers with weak CORS policies that will allow us to use an
arbitrary origin to initiate a request, possibly allowing us to also supply
credentials (cookies) for that server. To determine a target’s CORS policy, we
can quickly use curl:
curl -X "OPTIONS" -i -k https://<IP_ADDR>A CORS policy with a wildcard (*) like:
Access-Control-Allow-Origin: *Would allow a client to provide any arbitrary Origin header and complete a
cross-origin request, allowing the browser to provide the content to a
JavaScript script. Wildcard CORS policies don’t allow the
Access-Control-Allow-Credentials header to be set to true, and these CORS
policies have to be handled by the server’s application code. So, if an
arbitrary Origin is provided by the client, it’s like the server will parrot
the Origin provided and allow it to provide a credential.
Finally, there’s the possibility the application code is bad, and doesn’t parse
our provided Origin correctly. If we find a vulnerability in Origin
processing by fuzzing the Access-Control-Allow-Origin header, it’s possible we
can discover a domain that is allowed that wasn’t originally intended. We could
then purchase the domain and host our attacks from there.
A tool to scan targets for CORS misconfigurations can be found here (I haven’t gotten to work, yet, but maybe it’ll work for you):