Cross-site request forgeries have been known about for a long time, but few people seem to be paying attention. Notable web application security expert Chris Shiflett has been talking about them for years, yet you'll still find the vulnerability almost everywhere you look.

In a nutshell, a CSRF attack occurs when I put a form on my webpage that submits to a third party's website. When you visit my page, the form gets submitted to the third party. If you are logged in to that third-party page, and my form says "delete all my stuff," the third party will believe that you are submitting it, and delete all your stuff. This is bad if you like stuff, as most of us do.

Undoubtedly there are lots of websites with these problems, but our focus is on devices (i.e. hardware appliances). Many devices sold to businesses these days are managed through web interfaces that are accessed using a regular web browser like a normal website. This means that the devices managing a company's firewalls, spam filters, web proxies, network stoage, and VPN's are at risk.

People have pointed out the problems with CSRF in home routers. Linksys has known about the issue for almost a year, but apparently hasn't bothered to fix it. We decided to take another look at the other major vendors of home routers, and little surprise, they were all vulnerable. Some of them made the problem worse with their particular implementations.

It might be acceptable to say that we don't expect as much security from the home routers. However, some of the products we tested explicitly advertised being secure. The packaging of one wireless router shows the user's house being protected by a shield bubble (think Star Trek). Another product had VPN right in its name. The era of low expectations should be ending.

How about professional security appliances?

We also took a look at the professional security appliances. We were expecting better results. In some ways, security appliances are more at risk than home routers: people spend more time logged into them, and they usually don't enter their passwords via a pop-up that would catch the user's eye.

However, the professional firewalls we tested almost all had the vulnerability. Some did not have web interfaces, which exempted them.

We grabbed one or two products per company. Our products tended to be the low-end models, but we always grabbed the latest firmwares available. We operated under the theory that if the vulnerability had been fixed anywhere, the vendor would've fixed it everywhere.

Companies that only sell high-end equipment to large customers weren't tested. So no ArcSight ESMs, no Mazu Profilers, no Lancope StealthWatches. If your organization has one of these, once you know what to look for it's usually easy to test for yourself.

In the end, we found four appliances from "serious" players that have this vulnerability. These are not small companies; they have very large customer bases using their products to secure themselves.

So, exactly how serious were the problems? An attacker could do almost anything that a user sitting in front of the web interface could do. One simple and scary test was to create a new VPN tunnel without the user's knowledge, so that external attackers could tunnel inside the network. Opening up the device to allow remote administration was another example that greatly concerned us.

Defending against this as an end-user

As an end-user, there are some steps you can take to defend yourself, but all of them have limitations.

1. Use web management in isolation. Each browser instance should only connect to one device's web interface. Do not operate multiple windows or tabs when managing a device.

   As a suggested approach, you could use Firefox to browse the web while using Internet Explorer to manage only your firewall. You could also run your favorite browser inside of a virtual machine.

   There are ways around this, though. Some devices make it easy to log in with the default password via CSRF, so even if you really aren't logged in, the CSRF could force you in. If your assets are a big enough concern, set up a dedicated workstation for controlling your device, and block all other IP addresses from connecting to it.

2. Don't use the default passwords. Even a little bit goes a long way.
3. Log out of your web interface when not using it, and configure its inactivity timeouts.
4. Update to the latest version of your product's software. CSRF attacks have only recently gained popularity, so any device more than a few years old is very likely to be vulnerable to them.

   This didn't really help right now for most of the devices we tested, since most of the vendors didn't give anything beyond an auto-response when we contacted them.

5. Disable JavaScript. Note that many devices and websites require JavaScript to be enabled. Authorizing sites on a case-by-case basis to use JavaScript (such as with Firefox's NoScript plugin) can significantly reduce this vulnerability.

   (Please note that there may still be ways of exploiting this without JavaScript, but they generally involve social engineering or a poorly designed web interface.)

6. Disable Flash. Older versions of Flash allow a much deeper interface with network sockets than JavaScript does. As above, you can enable Flash on a case-by-case basis.
7. Operate your web management interface on a non-standard address and/or port. (Please note that this is security through obscurity, and although it may protect you from general attacks, anyone targeting you will likely be able to figure out the address.) Don't give it a name like "gateway" or "router".

Defending as a developer

If you are developing a web interface, here are the steps you need to be taking:

1. First things first: take care of XSS. Cross-site scripting attacks are a bit harder to implement, but easier for you to prevent. Anything that an end-user controls should not be emitted back to them without being cleaned and filtered
2. Put a unique field into each POST form. When you process the submitted form, check that the value submitted with the form matches the one that was supplied.

   This can be done on a user-by-user basis. If you have any kind of session logic, for example, you could create a magic number when the session is created, include it with every POST form, and check for that number on form processing.

3. Use POST instead of GET for anything with side-effects. This has been part of the HTML standard all along, but violations of the standard still occur regularly. There are lots of things that will break if your GETs have side-effects.

   Please note that using POST does not fix the problem. However, if you use GET, then it becomes a lot easier for someone to exploit any CSRF problems you have.

4. Reconsider your use of persistent browser authentication. Persistent authentication isn't necessarily wrong; at Calyptix we decided to stay with it. But you should consider the alternatives.

   One alternative is to embed an authentication string into every page and every URL, such that it's always submitted back to the browser. This can be complicated to engineer, and it runs the risk of that authentication string finding its way out. (URL's leak, whether through toolbars or referrer logs.) Of course, the authentication string shouldn't be reversible to the user's name or password.

5. Let the user log out, and provide timeout mechanisms. You can put expiration times on cookies. But remember that there is no guarantee that the browser will obey those timeouts. (According to the spec, it doesn't need to.)
6. Consider using the browser's native HTTP Authorization methods. HTTP has directives in which the server tells the browser to ask the user to put in their passwords. The browser pops up a window to let the user enter their credentials.

   Most modern websites view this method as archaic, preferring to let the user login with a pure HTML form. From a design point-of-view, the form is a much nicer interface. However, it lets CSRF attackers try to force a log-in without risking the end-user getting any suspicion of what is going on. Trying to log in to a site that uses HTTP Authorization will generate pop-ups if the end-user has not already logged in.

   HTTP Authorization is not without its drawbacks. Digest access authentication, while preventing the password from being sent in the clear across the network, generally requires that the server know the unhashed password. This doesn't scale well for large organizations that have many logins to the device. However, for small environments, such as homes and small businesses, the primary threat is not someone who already has physical access; it's someone on the Internet creating automated forms to attack your customers.

   Home routers should think carefully before moving away from HTTP Authorization.

7. Consider not using a web interface. This method is a bit extreme. Both developers and users like web interfaces because the user is already familiar with the look-and-feel of their browser, so it means they can become comfortable using your device quickly.

   But with that ease of use comes some danger. The common platform for development also means a common platform for attacks.

   Before scrapping your web interface for a custom UI, realize that your new UI will likely have its own security flaws. You shouldn't take this step without understanding that you aren't eliminating risks; rather, you are trading one set for another.

What doesn't help

1. HTTPS

   SSL won't help here. Most browsers will give a warning when switching back-and-forth between HTTP and HTTPS, but these are minor, and the attacker could thwart it by attacking from their own HTTPS site.

2. EV certificates

   Being very sure of the identity of the website doesn't mean that forged requests don't go through.

3. Biometrics and smart cards

   The means of giving the authentication isn't at issue. Unless the user needs to explicitly swipe his smart card through a reader for every transaction, this doesn't make a difference.

Moving forward

It's about time appliance vendors woke up to the problem of CSRF and how serious it is. The slackness of generic websites to address this issue isn't an excuse; if anything, the security vendors should be leading the way.

We only found two products from two companies that had web interfaces that were hardened against CSRF.

Since we follow responsible disclosure, we haven't revealed the companies that aren't responding. At our last count, we were still waiting to hear back from 7 vendors. (And this will probably go up as we test more devices.)

These are vendors we tested that have the problem fixed. Not seeing a vendor here does not mean they are vulnerable; it may mean that we just haven't had an opportunity to test their device.

We wish to applaud the companies that respond promptly and positively to security reports, as it helps encourage more use of responsible disclosure.

Fixed after we contacted then:
• Check Point (Safe@Office)

Fixed, but wouldn't say so:
• eSoft (Instagate EX2)

Fixed by the time we started looking:
• Astaro (Security Gateway)
• Barracuda (Web filter)
• Calyptix Security (of course :D )