If you’re the “average Web user” using unmodified versions of the most popular browsers can do relatively little to prevent cross-site request forgery.
Logging out of sites and avoiding their “remember me” features can help mitigate CSRF risk, in addition — not displaying external images or not clicking links in spam or untrusted e-mails may also help. Browser extensions such as RequestPolicy (for Mozilla Firefox) can prevent CSRF by providing a default-deny policy for cross-site requests. However, this can significantly interfere with the normal operation of many websites.
The CsFire extension (also for Firefox) can mitigate the impact of CSRF with less impact on normal browsing, by removing authentication information from cross-site requests.
Web developers, however have a better fighting chance to protect their users by implementing counter-measures such as:
- Requiring a secret, user-specific token in all form submissions, and side-effect URLs prevents CSRF; the attacker’s site cannot put the right token in its submissions
- Requiring the client to provide authentication data in the same HTTP Request used to perform any operation with security implications (money transfer, etc.)
- Limiting the lifetime of session cookies
- Checking the HTTP Referer header
- Ensuring that there is no clientaccesspolicy.xml file granting unintended access to Silverlight controls
- Ensuring that there is no crossdomain.xml file granting unintended access to Flash movies
- Verifying that the request’s header contains a X-Requested-With. Used by Ruby on Rails (before v2.0) and Django (before v1.2.5). This protection has been proven insecure under a combination of browser plugins and redirects which can allow an attacker to provide custom HTTP headers on a request to any website, hence allow a forged request.
Checking the HTTP Referer header to see if the request is coming from an “authorized” page is a common tactic employed by embedded network devices due to the low memory requirements. However, a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary http request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an http request. To prevent forgery of login requests, sites can use these CSRF countermeasures in the login process, even before the user is logged in. Another consideration, for sites with especially strict security needs, like banks, often log users off after (for example) 15 minutes of inactivity.
I hope this helps when dealing with this malicious exploit. Let me know how it works out for you. Meanwhile, stay safe out there!
RT @MicroSolved: Malicious Exploits: Hitting the Internet Waves with CSFR, Part 2. Now we have the good stuff! http://t.co/qEJxcAc5 #security #in
Pingback: Malicious Exploits: Hitting the Internet Waves with CSRF, Part One - MSI :: State of SecurityMSI :: State of Security