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
, 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
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
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
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.
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.
Don't use the default passwords. Even a little bit goes a long way.
Log out of your web interface when not using it, and configure its
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.
Firefox's NoScript plugin) can
significantly reduce this vulnerability.
(Please note that there may still be ways of exploiting this without
poorly designed web interface.)
Disable Flash. Older versions of Flash allow a much deeper
can enable Flash on a case-by-case basis.
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
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
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.
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.
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.
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.)
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
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
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
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
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.
- EV certificates
Being very sure of the identity of the website doesn't mean that
forged requests don't go through.
- 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.
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
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
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 by the time we started looking:
- Astaro (Security Gateway)
- Barracuda (Web filter)
- Calyptix Security (of course :D )