Paid Advertising
web application security lab

Reducing CSRF Risk With Tiered Authentication

One of the largest dangers with authentication is that once you are authenticated you’re free to visit any page that sits behind the authentication. That wouldn’t be such a huge risk for web application security except for the fact that cross site request forgeries (CSRF) can force you as a user to bounce around within a website without meaning to (at the mercy of your browser, really). So what should you to do mitigate that risk?

I’m not going to give you the full run down on how to stop CSRF because honestly, it’s a huge mess, and with things like the Expect vulnerability in Flash allowing you to read/write from a host, tons of those old methods are broken anyway. The one thing that hasn’t been broken is user interaction. CSRF works because in general it does not require user interaction. Things that rely on unique numbers outputted only work if you can’d get the user to do an XMLHTTPRequest to read the page and replay it, just like the browser would. Trust me, it works. If the site is cross site scriptable (and they almost all are) the method of using unique strings is pretty broken. But there is another way.

Why can’t we ask the user for something? Something that a scanner cannot scan for or know. A userid is too weak and a known entity, but what about their password? Why not stop them in the middle of the flow and say, “Hey, are you really sure you want to change your password?” It doesn’t require a lot from the user, and it’s something that is impossible to session ride without. Of course, you can phish for the username and password, and get the same effect, but that’s far more difficult than a simple image tag CSRF attack.

Yes, there are problems with this, but let’s think about what you are really trying to solve. The vast majority of your users could use a lower level of authentication for the day to day things they are doing (like posting to a web-board for instance). Maybe they have to log in again to change billing information or request information from other users (which could be used as spam). And maybe there is a third level of authentication that asks the user for a username and password when they are doing something like changing account information that could allow for a compromise (like their mother’s maiden name for instance).

You are talking now about the statistical liklihood that the user is in that state. Most of the time they are only in the first state where they cannot do anything but post. That way the statistical liklihood of being able to force the user to perform a malicious function is a factor of how likely it is that a user is in the appropriate level of authentication (which should be very uncommon). In this way you can reduce your overall attack surface to a vast minority of users without some other attack vector (like phishing or credential tampering). Security in layers could start with something as simple as reducing what your users can do without authenticating again.

6 Responses to “Reducing CSRF Risk With Tiered Authentication”

  1. Legionnaire Says:

    Yeah, using layers of security makes it much more difficult for such attacks and many others e.g. leaving the room with your computer, physically accessible, logged in a session.

    Some packages like phpBB and commercial Business2Business platforms have that kind of security by default. I guess you are talking about custom, build-from-scratch web platforms which are generally a bad idea for a million or so reasons.

  2. RSnake Says:

    Hahah, probably… you want to give me a few of those reasons? It would be interesting to hear your views on them, actually. I think home-brew apps have just as much chance of successfully circumventing vulnerabilities as widely spread open source applications, strictly due to obfuscation, but I have no provable reasons to argue that, only anecdotal.

  3. Legionnaire Says:

    Just a quick reply here…

    home-brew apps have also the same bugs-per-line ratio. Maybe it’s easier to identify them and fix them but that doesn’t mean your product is bug-free.

    To top that, think that not everyone is as good a programmer as he/she thinks. So maybe you say “I can do it better than XYZsoft Inc.” and maybe you can but it is more likely you cannot.

    Another thing is you can’t really stress test you app. When someone asks you to come up with a custom-made solution, he usually wants it relatively fast. I don’t thing anyone will pay you for let’s say two years to deliver an excellent app. Maybe for six months or a year max. In that time you barely have time to write it and make sure it doesn’t randomly crash :P

    In any case, if a company cannot affort a package-solution, how much money will it spend on a home-brew app? The number one reason in favor of custom solutions is the low cost. It’s really sad budget is a major criteria but what can you do?

    Anyway, just a few thoughts here. Also, it’s really unproductive to spend your time and money developing something so specific that cannot be used in another case. This applies if you are working as a free-lance programmer. If you are full-time in a company you always work on something too specific. That’s really another issue but worth mentioning.

  4. RSnake Says:

    I’m no stranger to the economics of vulnerabilities, and I agree completely that it’s easier to build an application quickly than quickly and securely, and it’s even faster to build an application that you didn’t actually build at all, but just unzipped and configured. I think I was really targeting this towards the developers themselves and/or the people who are capable of developing these applications themselves.

    But I’m one to talk, right? I’m using a (modified) version of Wordpress, not a homebrew application. But I’m also not using PHPNuke either, so I’m not a complete hypocrite. :) But your point is well taken, Wordpress isn’t suited to everyone, and sometimes building your own app is well outside your abilities/timeframe so you have to look for alternatives.

    But I would caution anyone using PHPNuke to turn off everything first, and turn on only what is actually needed. That’s the only thing that saved us from a bout of automated scanners when I was first scanning it. We had a vulnerable application it was just turned off at the time while I was auditing it, thankfully.

  5. RSnake Says:

    I should point out something that was brought to my attention, tiered authentication is really most useful against _SAME_ site request forgeries, rather than cross site request forgeries. Obviously it makes no difference if you are sending traffic off host. Well, it may make some incremental small difference if the XSS that enables the CSRF is hidden behind password verification/user input, but that’s a stretch.

  6. BoogerKlown Says:

    Hey all, I actually make web-apps. I know security is a big issue. I really like the idea of tiered Authentication. If you want to enhance it some. If you are using a database (which i assume you are) . I find that when creating an app and your looking for max security. Defensive programming is the way to go. I often find that a good class/object structure for the app always works out best. You can maintain minimal connection with the database, have functions that parse user input for errors and using active record techniques means that you can also set up defenses against certain types of injection attacks. Also for testing your apps use unit testing. I find that when unit testing i can test every single line of code and how it interacts with eachother. It takes time and tedious but you can write your own unit test classes to make it easier. Also watchout when using open source stuff. the one disadvantage is that people can take a peek at the base code and have a basis for attacking your app. Of course those are the elitist haha. But if you are going to create your own apps being heavy object oriented. Also you never allow you basic users to gain access to anything truley vital to the app itself. If you are working with stuff like billing, remember https XD. I guess thats my 50 cents. sorry for the long winded post. But definately the multi tiered authentication is pretty good.

    P.S. As an addition to it, you could store a unique 32 char id for each level of authentication for a user that gets passed through the $_SESSION data of course there are the issues with that. Also for even more security encrypt all sensitive data that goes out. If you don’t encrypt it then your not being fair to your users. Well PEACE!