Defending Against CSRF Attacks: Prevention and Best Practices
Learn how to defend your web application against CSRF attacks, which can allow hackers to exploit authenticated user sessions. Discover the importance of header verification, CSRF tokens, and anti-CSRF coding best practices to mitigate the risks associated with CSRF attacks.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
DEFENDING AGAINST CSRF ATTACKS Based on the book Web Application Security: Exploitation and Countermeasures for Modern Web Applications by Andrew Hoffman (2020)
WHAT AND WHY? Recall: A hacker may use CSRF attacks to take advantage of a user s authenticated session in order to make requests to the server on behalf of the hacker (unknowingly). CSRF-style attacks function at an elevated privilege level and often are undetectable by the authenticated user. 2
HOW? Header Verification CSRF Tokens Anti-CRSF Coding Best Practices 3
HEADER VERIFICATION Recall: CSRF attacks are built with <a></a> links, via <img></img> tags, and even via HTTP POST using web forms. Because the origin of many CSRF requests is separate from your web application, we can mitigate the risk of CSRF attacks by checking the origin of the request. Two HTTP headers are of interest: Origin header Referer header 4
HEADER VERIFICATION (CONT.) Origin Header It is a simple header that indicates where a request originated from. The origin header is only sent on HTTP POST requests. Unlike referer, this header is also present on HTTPS requests, in addition to HTTP requests. e.g., Origin: https://www.mega-bank.com:80 5
HEADER VERIFICATION (CONT.) Referer Header The referer header is set on all requests. The referer header also indicates where a request originated from. - The only time this header is not present is when the referring link has the attribute rel=noreferer set. e.g., Referer: https://www.mega-bank.com:80 6
HEADER VERIFICATION (CONT.) Referer Header (cont.) When a POST request is made to your web server for example, https://www.megabank .com/transfer with params amount=1000 and to_user=123 you can verify that the location of these headers is the same as your trusted origins from which you run your web servers. 7
HEADER VERIFICATION (CONT.) Weaknesses? a) Header verification will fail to protect your application should an attacker get an XSS on a whitelisted origin of yours. The hacker can initiate the attack from your own origin, appearing to have come from your own servers as a legitimate request. b) If your website allows user-generated content to be posted, validating headers to ensure that they come from your own web servers may not be beneficial at all. Lesson? It is best to employ multiple forms of CSRF defense with header verification being a starting point rather than a full-fledged solution. 8
CSRF TOKENS The most powerful form of defense against CSRF attacks is the anti- CSRF token, often just called a CSRF token. Most major websites rely on CSRF tokens as their primary defense against CSRF attacks. 9
SOURCE: HTTPS://PORTSWIGGER.NET/WEB-SECURITY/CSRF/BYPASSING-TOKEN-VALIDATION 10
CSRF TOKENS (CONT.) CSRF token defense works like this: 3. As a result of requests requiring a valid CSRF token, which is unique per session and unique to each user, CSRF attacks originating from other origins become extremely difficult to pull off. 1. Your web server sends a special token to the client. This token is generated cryptographically with a very low collision algorithm, which means that the odds of getting two identical tokens are exceedingly rare. The token can be regenerated as often as per request, but generally is generated per session. Not only would the attacker need a live and up-to-date CSRF token, but they would also now need to target a specific user versus a large number of users. 2. Each request from your web application now sends the token back with it; this should be sent back in forms as well as AJAX requests. When the request gets to the server, the token is verified to make sure it is live (not expired), authentic, and has not been manipulated. If verification fails, the request fails and is logged. Furthermore, with token expiration implemented, CSRF tokens can be dead by the time a user clicks a malicious link a beneficial side effect of CSRF tokens as a defensive strategy. 11
CSRF TOKENS (CONT.) Stateless CSRF Tokens In modern web applications, statelessness is often a prerequisite to API design. A stateless design refers to a system architecture where each request is handled independently of any previous requests. Exercise: What are the benefits of a stateless design? CSRF tokens can be easily added to stateless APIs, but encryption must be involved. A stateless CSRF token should consist of the following: A unique identifier of the user the token belongs to A timestamp (which can be used for expiration) A cryptographic nonce whose key only exists on the server 12
ANTI-CRSF CODING BEST PRACTICES Common methods of eliminating or mitigating CRSF risk in your web application: Stateless GET requests Implementation of application-wide CSRF defenses by, for example, using request- checking middleware 13
ANTI-CRSF CODING BEST PRACTICES (CONT.) Stateless GET Requests Recall: The most common and easily distributable CSRF attacks come via HTTP GET requests. HTTP GET requests should not store or modify any server-side state. HTTP GET requests are at risk by default; the nature of the web makes them much more vulnerable to CSRF attacks, and should be avoided for stateful operations. 14
ANTI-CRSF CODING BEST PRACTICES (CONT.) Stateless GET Requests (cont.) This first API combines the two operations into a single request, with an optional update. can be taken advantage of by CSRF in any HTTP GET (e.g., a link or image: https:///user?user=123&update s=email:hacker). 15
ANTI-CRSF CODING BEST PRACTICES (CONT.) Stateless GET Requests (cont.) This revised API splits retrieving and updating users into a GET and a POST request, respectively. The API, while still an HTTP POST and potentially vulnerable to more advanced CSRF, cannot be taken advantage of by links, images, or other HTTP GET-style CSRF attacks. 16
ANTI-CRSF CODING BEST PRACTICES (CONT.) Application-Wide CSRF Mitigation (using an anti- CSRF middleware) Most modern web server stacks allow for the creation of middleware or scripts that run on every request, prior to any logic being performed by a route. Such middleware can be developed to implement these anti-CSRF techniques on all of your server-side routes. 17
ANTI-CRSF CODING BEST PRACTICES (CONT.) Application-Wide CSRF Mitigation (using an anti-CSRF middleware) (cont.) 18
SUMMARY CSRF attacks can be mitigated for the most part by ensuring that HTTP GET requests never alter any application state. Further, CSRF mitigations should consider validating headers and adding CSRF tokens to each of your requests. Implementing those methods as application-wide CSRF mitigation (e.g., using an anti-CSRF middleware) 19
