Filed under: IIS & HTTP
What is a Cross Site Request Forgery Attack?
Cross-site request forgery (CSRF or XSRF) is an attack that has been in the OWASP Top 10 since its inception, but is not nearly as talked about as other OWASP lifers like XSS or SQL injection. We’ve decided to give CSRF some needed attention and discuss some ways to mitigate it.
Also known as a “one click attack” or “session riding,” CSRF an exploit very similar to an XSS attack. Rather than an attacker injecting unauthorized code into a website, a cross-site request forgery attack only transmits unauthorized commands from a user that the website or application considers to be authenticated.
Certain websites and applications are at risk: those that perform actions based on input from trusted and authenticated users without requiring the user to authorize the specific action. These attacks are characteristic vulnerabilities of Ajax-based applications that make use of the XMLHttpRequest (XHR) API. A user that is authenticated by a cookie saved in his Web browser could unknowingly send an HTTP request to a site that trusts him and thereby cause an unwanted action (for instance, withdrawing funds from a bank account).
The most common way to prevent CSRF is by setting a one-time key, or nonce (number used once). This concept can be seen on sites that require challenge-tokens for forms dealing with sensitive data, such as online banking forms or login forms. When a user authenticates an account on, say, a banking site, a randomly generated token would be set containing a random string of numbers. When subsequent requests are made, the request would include the token, which is verified by the server. By setting this unique token for every session or even every request, it prevents forms on other sites from exploiting an active session. A malicious site would need to guess the token in order to exploit this method.
Number used once (nonce)
A nonce, in information technology, is a number generated for a specific use, such as session authentication. In this context, “nonce” stands for “number used once” or “number once.”
Typically, a nonce is some value that varies with time, although a very large random number is sometimes used. A nonce can be a time stamp, a visit counter on a Web page, or a special marker intended to limit or prevent the unauthorized replay or reproduction of a file.
Source: Tech Target
Stopping CSRF with ServerDefender VP
Knowing the severity of CSRF attacks, we built in several controls to help prevent them in our ServerDefender VP (SDVP) web application firewall. For those using SDVP who’d like to add an extra layer of CSRF protection, we’re going to outline how to do so.
Enforcing session expiration
One way to prevent CSRF using ServerDefender VP is to enforce session expirations (inactivity timeouts). This is especially important if the timeout is set for a relatively brief period, such as 15 minutes. This can be done in an application as well, but ServerDefender VP sets its own cookie and can thus enforce its own session timeout. This renders all current cookies invalid, regardless of whether the app is handling session timeout properly or not.
Bind the Session to Referer
Binding the session to the HTTP referer is another method that can be used to prevent CSRF with ServerDefender VP. For well-behaved proxies, binding the session to the client IP address can be another potential method, using the X-Forwarded-For. These options make it very difficult for malicious code to use an existing session to issue arbitrary requests. There is, however, a downside to this strict Referer and/or IP session validation: any legitimate browsers and/or proxies that omit the Referer, and any proxies that change the client IP without setting an appropriate X-Forwarded-For header, will cause false positives. In order to mitigate false positive risk, these session hardening options should be used with caution. Testing in Log Only mode, before making them live in production is also recommended. However, use of these options won’t likely cause issues with sites utilizing HTTPS. If you’d like to see more about how SDVP works, check out the 30 day trial.
Stopping CSRF with LinkDeny
We created LinkDeny primarily as an anti-leeching tool, to put organizations back in control of who links to their content. LinkDeny has access controls to block downloads of content based on things like a requestor’s IP address, referring URL, country, and existence of cookie. A beneficial side-effect of these control capabilities is a solid level of CSRF protection.
Time Limiting Test
The Time Limiting feature allows admins to put time limited access keys on certain content. This feature requires some code changes to get the full effect, which involves inserting a URL mask into every URL reference in the code, that submits data (whether using POST or GET) to the application, such that, e.g.:
would have to be rewritten in code with a URL mask in place:
LinkDeny would then read that code as it is being sent out from the server, detect the URL mask in the page, and replace it with a nonce, before sending the entire HTTP response. The resulting line of code that actually gets sent to the browser would look like:
Note the random number string now in the URL. The form could then be submitted to that URL for a limited time, but not to the “real” location (i.e., /actionpage.cfm), which would always be unreachable and protected. Thus in order to carry out a successful CSRF, the malicious code would not only have to take advantage of a live session, it would have to somehow figure out that random URL path, and use it before it expires. So in effect, this feature of LinkDeny makes the URL whereby one gets access to the vulnerable resource user-unique and temporary, whereas CSRF counts on vulnerable URLs being stable from visitor to visitor and over time. If you’d like to check out his feature can access a trial of LinkDeny, as well. We hope this helps with your CSRF-prevention, but as always, if you have any questions we’re always glad to help.No Comments »