Tag Archives: tokens

Malicious Exploits: Hitting the Internet Waves with CSRF, Part Two

Posted on by
2

 

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.

One simple method to mitigate this vector is to use a CSRF filter such as OWASP’s CSRFGuard. The filter intercepts responses, detects if it is an html document, and inserts a token into the forms and optionally inserts script-to-insert tokens in ajax functions. The filter also intercepts requests to check that the token is present. One evolution of this approach is to double submit cookies for users who use JavaScript. If an authentication cookie is read using JavaScript before the post is made, JavaScript’s stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain.

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.

Using the HTTP specified usage for GET and POST, in which GET requests never have a permanent effect, while good practice is not sufficient to prevent CSRF. Attackers can write JavaScript or ActionScript that invisibly submits a POST form to the target domain. However, filtering out unexpected GETs prevents some particular attacks, such as cross-site attacks using malicious image URLs or link addresses and cross-site information leakage through <script> elements (JavaScript hijacking); it also prevents (non-security-related) problems with some web crawlers as well as link prefetching.

I hope this helps when dealing with this malicious exploit. Let me know how it works out for you. Meanwhile, stay safe out there!

Another Good Reason to Increase Internal Security

Posted on by
Reply

Well, the much anticipated 2010 Verizon Data Breach Investigations Report is out, and once again it is an eye-opener! Let me say what a boon these reports are to the infosec community! Verizon and their team are to be praised and congratulated for all their hard work. These reports really help us keep current so we can protect our information from the right threats in the right ways. I know it’s not a large scale study, but I do feel it gives us good indications of trends and threats in the industry.

This particular threat report mainly gives us the data breach picture for 2009. It was compiled from nearly 900 actual incidents and includes a lot of input from the U. S. Secret Service this year. One of the surprising results of this particular report was the 26% increase in data breaches from insiders. It seems that organized cybercriminals are promising money to insiders with access to administrator level credentials. Unfortunately for these naïve inside individuals, it is proving very easy for the authorities to catch them. Also, it seems, the cybercriminals are usually not even paying them as promised! Despite these facts, it is evidently fairly easy to find plenty of insiders that are willing to sell their credentials. Go figure!

There are several ways to help counter the insider threat. The easiest thing you can do right off the bat is to ensure that those with high level access to the system don’t use the same credentials for their administrator and user accounts. You’d be amazed at what a common practice this is! All cybercriminals have to do is bust a few user level accounts and there is a VERY good chance that they will then be able to gain administrator level access. Administrator level passwords should be long, strong and ONLY used for administration purposes.

Another very effective method to counter the insider threat is to use true multi-part authentication mechanisms for administrative level access to the system; especially with very effective mechanisms such as tokens. Employing this practice means that cyber criminals not only have to steal credentials, they also have to get their hands on a token. And even if they do, it only gives them a short time to act; admin tokens are usually missed very quickly. There is also the option to employ biometrics. These can be problematic, but are improving all the time. And effective and reliable biometrics are even harder to overcome than token use.

You might say that good passwords, biometrics, and tokens won’t keep actual system and database administrators from selling out to the bad guys, which is true. However, there are other mechanisms available that can prevent lone bad-actors from compromising the system. One effective practice is management monitoring of high level access. If, every day, managers are looking at who accesses what and when, then the difficulty of stealing or corrupting data goes WAY up! Also, there are applications out there that can send out alerts when high level access is underway.

Another method, and a tried and true one, is the use of dual controls. If it takes two individuals to access systems, then cybercriminals have to corrupt two individuals and it becomes even easier for the authorities to figure out who the rats are. I don’t recommend this control except for very high value assets. The downside is that it’s a hassle to implement. There ALWAYS has to be at least two individuals available at all times or access becomes impossible. There are vacations, lunches and breaks to consider, and what happens in true emergencies such as floods, snow storms and the like? But this is a control that has been in use since long before computer systems were in place and it has proven to be very reliable.

These certainly aren’t all of the controls available to help counter the inside threat. I’m sure that you can come up with some others if you give it a little thought. But used individually, or even better, in combinations, should go a long way in protecting your data from the bad guys within!