# CSRF #### Basic usage CSRF conditions: 1. Relevant action like change mail 2. cookie-based session handling 3. no unpredictable request parameters **Identify a Vulnerable Action** * Find an action on the target web application that requires authentication and can be executed via a simple HTTP request (e.g., form submissions, changing user settings, transferring funds, etc.). * Common targets include: * Form submissions (changing email, password). * Sensitive actions like transferring funds or making purchases. * Any action that requires the user to be logged in. **2. Check for Lack of CSRF Protection** * Confirm that the web application does not include anti-CSRF tokens in the request. Common CSRF protection mechanisms include: * **CSRF tokens**: Unique tokens embedded in forms or URLs that must be submitted with requests. * **SameSite cookie**: Cookies marked as `SameSite` prevent CSRF attacks because they are not sent with cross-origin requests. If none of these protections are in place, the application might be vulnerable to CSRF. **3. Capture the Legitimate Request** * Using a tool like **Burp Suite** or browser developer tools, capture the legitimate request that performs the sensitive action (e.g., submitting a form, changing user details). * Look at the method (`GET`, `POST`), URL, and parameters. A common CSRF target is a `POST` request that changes user data, but `GET` requests can also be vulnerable. Example of a simple `POST` request to change an email address: ```http POST /change-email HTTP/1.1 Host: vulnerable.com Cookie: sessionid=12345 Content-Type: application/x-www-form-urlencoded email=newemail@attacker.com ``` **4. Craft a Malicious HTML Form or Script** * Create a malicious HTML page or script that automatically submits the request on behalf of the victim when they visit the page. This can be done by creating a hidden form that triggers a `POST` request or an image/link for `GET` requests. If you're using [Burp Suite Professional](https://portswigger.net/burp/pro), right-click on the request and select Engagement tools / Generate CSRF PoC. Enable the option to include an auto-submit script and click "Regenerate". #### Referer Validation CSRF ***Identify*** the change email function is vulnerable to CSRF by observing when the **Referer** header value is changed the response give message, `Invalid referer header` > Adding original domain of target and append `history.pushState('', '', '/?TARGET.net');` to the **Referer header** in the form of a query string, allow the change email to update. ``` #header need to be present on the exploit server Referrer-Policy: unsafe-url #header is accepted so it's possible to change mail from the exploit server Referer: https://arbitrary-incorrect-domain.net?YOUR-LAB-ID.web-security-academy.net ``` ``` ``` ### No Referer needed Add no-referrer meta tag inside body in POC to surpress no referer ``` ``` ## CSRF where token is tied to non-session cookie csrf and csrfKey is tied together but no session cookie 1. need to inject csrf in the form of POC -> easy 2. find a way to inject csrfKey to the user -> harder 1. Need an action with set-cookie parameters in response ```

``` ### CSRF duplicated the value of the `csrf` body parameter is simply being validated by comparing it with the `csrf` cookie, so we can put any value to it, just put same value in the form and cookie set with search fn ```

``` ### Ignore CSRF Token Just POC without csrf ``` ``` ### Method change to bypass csrf token checks GET /my-account/change-email?email=d%40d.d HTTP/2 Host: 0a2100d30342205281e74d70008b00fe.web-security-academy.net Cookie: session=EqmLZBceqoIkYKB1J1jdeWunTNUoP1Tf Cache-Control: max-age=0 #### Is Logged In > If cookie with the **isloggedin** name is ***identified***, then a refresh of admin password POST request could be exploited. Change username parameter to administrator while logged in as low privilege user, CSRF where token is not tied to user session. ``` csrf=TOKEN&username=administrator ``` #### SameSite=Strict bypass Cross-site WebSocket hijacking (also known as cross-origin WebSocket hijacking) involves a [cross-site request forgery](https://portswigger.net/web-security/csrf) (CSRF) vulnerability on a [WebSocket handshake](https://portswigger.net/web-security/websockets/what-are-websockets#how-are-websocket-connections-established). It arises when the WebSocket handshake request relies solely on HTTP cookies for session handling and does not contain any CSRF tokens or other unpredictable values. ``` ``` SameSite=Lax bypass Observe if you visit `/social-login`, this automatically initiates the full OAuth flow. If you still have a logged-in session with the OAuth server, this all happens without any interaction., and in proxy history, notice that every time you complete the OAuth flow, the target site sets a new session cookie even if you were already logged in. ```

Click anywhere on the page

``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://oscp-7.gitbook.io/bscp-notes/stage-2/csrf.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.