In Burp Suite Pro, you can use the tool to demonstrate a CSRF vulnerability by creating a proof of concept (PoC) using a request that does not include a CSRF token. This request can be used to update client information, and will show how an attacker can exploit the lack of CSRF protection to make unauthorized changes. **Right Click --> Engagement Tools --> Generate CSRF PoC** - POST REQUEST --> HTML (What the evil server would have) ```html
``` - Go in options and use auto-submit to include this line `...>document.forms[0].submit();<...` - Take note that in the following example we have added the following from the original PoC of BurpSuite Pro GET REQUEST --> HTML (What the evil server would have) ```html ``` ## No CSRF Protection Another way to test for vulnerabilities related to CSRF is to observe if the application does not have any CSRF token implemented. This can be done by checking the requests made by the application and verifying if there are any tokens being used to protect against CSRF attacks. If there are no tokens present, it may indicate a vulnerability in the application's security. Steps: - Generate a template - Append automation ## Remove CSRF Token Another way to test for vulnerabilities related to CSRF is to observe if the application's security can be bypassed by removing the CSRF token from a request. This can be done by intercepting a request that includes a CSRF token, removing the token, and forwarding the modified request to the server to see if it is still accepted. If the request is accepted without the token, it may indicate a vulnerability in the application's CSRF protection. Steps: - Remove the token - Test if the request work - Generate a template - Append automation ## Change Request Type Another way to test for vulnerabilities related to CSRF is to observe if the application's security can be bypassed by changing the request type from POST to GET. This can be done by intercepting a POST request that includes a CSRF token, changing the request method from POST to GET, and forwarding the modified request to the server to see if it is still accepted. If the request is accepted without the token, it may indicate a vulnerability in the application's CSRF protection. Steps: - Select in Burp Suite (repeater) the "Change request method" --> Change POST to GET - Generate a template - Append automation ## Client-Side Redirect The process of changing a user's email address may be hindered by security measures such as the refer header, which requires the user to first visit a page on the website before making changes. However, if a client-side redirect vulnerability is discovered, an attacker may be able to exploit it for a CSRF attack. This is done by crafting a GET request in the redirect, which can then be used to perform malicious actions, such as changing various informations. Steps: - Find a redirection vulnerability (Example redirect to post ID, but input ".."" take off the id and perform redirection) - Create a request for changing variable (Ex: email) - Change the request for a GET request ---> Dont forget, you might need to URL encode elements - Try appending the request (redirection) with the GET request - Generate a template from the redirection and change the value of the variable for the GET request - Append Automation ## Change Request Type (Overwrite) It may not be possible to change a POST request to a GET request, but it is sometimes possible to override this by modifying the PoC provided by BurpSuite and forcing the request to be made via a GET request. Steps: - Select in Burp Suite (reapeater) the "Change request method" --> Change POST to GET - Generate a template - Append automation - Hide the POST request with following input `