I think the best way would be to have a application firewall (as you said), I will try to code it.
Thank’s Delixe and pdp.

It is even more trivial to generalize this with a simple PHP class that will generate the form for you and do the rest. The problem is that the larger the application gets the more tedious this method is. I guess it is much better to do some kind of smart layered filtering where a top level application firewall modifies the form with all necessary information. I don’t think that you can do that with mod_security but a little bit of perl will do.

And, hei, your English is not that bad. Cheers.

You can just plug sessions vars in the action portion of a form and neutralize all attempts of CSRF since the attacker can’t possibly know the session string.

(Sorry for my english, I am from Argentina)
Thank you for doing such a great blog.

there are many of them. I am quite sure that you can find at least one framework per programming language.

.NET for example has the __VIEWSTATE. I don’t like transmitting so much data back’nfort to the client but, hey, that is by default and it protects your from CSRF. Microsoft has just released their Anti-XSS Library, I am not sure if that helps in terms of CSRF as well.

However, although there are available frameworks that more less prevent CSRF on your applications you must understand that none of them are AJAX compatible. As Billy Hoffman suggested on a few occasions, AJAX technologies are not completely understood and that makes them a lot more hackable. These are not his exact word but the context is the same.

CSRF skeptics would say “How the hell would an attacker fool me to visit a third-party site, while I’m still *logged on* to https://www.nameOfBank.com

Well, unfortunately there is a web browser feature that is becoming more and more popular which will make CSRF attacks even more feasible in the future. It’s called TAB BROWSING. The more web users do tab browsing, the more victims that will get CSRFed.

Check out the following scenario:

1. Victim is reading a blog
2. Victim opens new tab (without closing the already-open tabs) and logs into https://www.nameOfBank.com

What if the blog that was still open in a different tab had injected a script snippet that submits a CSRF attack to https://www.nameOfBank.com every X seconds in the background?

Guess what, you’ve just been robbed :-D

As pdp reminded us, we should consider splogs as a vector for maximizing the chances of successful exploitation.

I don’t think that’s a fitting example considering how many users are going to be logged in their router interface

Guys, we need to remind ourselves that many routers have vulnerabilities on their web interfaces which when combined with CSRF can potentially allow you to gain internal access to a network WITHOUT requiring the victim user to be authenticated.

Consider an authentication bypass vuln

http://www.securityfocus.com/bid/19347/discuss

By simply visiting the following URL, you just changed configuration settings on your router (if vulnerable) WITHOUT needing to be authenticated:

http://ikwt.com/projects/links....._test.html

Also consider an unauthenticated access to the router’s config file vuln. If combined with an XSS vuln, an attacker should be able to steal your router’s config file by using XMLHttpRequest() in the XSS payload:

http://www.securityfocus.com/bid/19057/discuss
http://ikwt.com/projects/btvoyager-getconfig.txt

What does have access to a router interface do?

If you can make admin requests to a router’s web inteface then you just gained internal access to the target network, by setting port forwarding for instance, or placing internal hosts on the DMZ.

you can hit a lot of random web users by spawning splogs for example

Automated CSRF, that’s a very good point!

let’s say that you have a router vulnerable to CSRF (all of them are)

Actually I don’t agree with this statement. While I would say that *most* router’s web interfaces are vulnerable to CSRF, not all are. For instance, BT Voyager 2091 router adds a token to all admin HTTP requests that change configuration settings.

i.e.:

http://192.168.1.1/lancfg2.cgi.....anmtu=1500

In this case the attacker needs to know the value of ‘checkNum’ when CSRFing, which is really assigned from the variable ‘randomNum’ within a JS snippet. ‘randomNum’ changes each time a page is loaded. YES, I’m sure that you can reverse engineer the router and figure out how the random token is generated (especially since the software is open source), but the point here is that BT kept in mind CSRF attacks when designing the web interface for Voyager 2091.

I do believe that routers’ web interfaces will be designed in the future using randomly-generated tokens for all configuration requests. But since now most people don’t have a damn clue what CSRF is and why it can be bad thing, there is still a lot of opportunities (and time) for exploitation.

Here is the article

http://wasjournal.blogspot.com.....e-for.html

The protection mechanisms to prevent CSRF seem rather difficult to apply and rather cumbersome to say at the least. I know I would hate to apply that with every damn form or many.

Yes, however, this is what frameworks are for. They are designed to save your time. Still, people like writing things themselves.

Many thanks.

I’ve seen the acronym CSRF quite often, I was interested in what the buzz was all about.

Thank you for clarifying, yes the combination of CSRF and persistent XSS can be deadly — I can definitely see that.

The protection mechanisms to prevent CSRF seem rather difficult to apply and rather cumbersome to say at the least. I know I would hate to apply that with every damn form or many.

The purpose of CSRF is to perform actions on behalf of the current user but this user must be authenticated first. Otherwise, there is no point in doing whatsoever.

Ok, here is another one: let’s say that an attacker wants to transfer some money to his/her account. They start a splog network which is backdoored from top to bottom with malicious JavaScript. The attacker targets several banks at the same time. So he/she has CSRF for Lloyds, Natwest, HSBC and some other bank. Once an unaware user visits any page from this splog network a CSRF will be executed to all bank sites initiating a money transfer. Most of the requests will fail, however, if the current user is unlucky enough to have their account open at the same time, or they forgot to logoff, the transfer will be successful.

As pagvac, put it very clear, CSRF in combination with persistent XSS could be quite dangerous. Why? Well, let’s say that someone targets MySpace with a similar exploit as the one discussed above. A worm like that could reach a critical mass in less then an hour effecting millions of users. Even if only 0.5% of them have their account open, the attacker could collect substantial amount of money.

Sometimes I see that attack vectors discussed in this blog are tried for real. I’ve seen some of them in the wild. The QuickTime attack on MySpace is just one of them. I hope that you won’t try this thing at home. Right?

What does have access to a router interface do? You can play around with ports and such but what else? (Yes I am ignorant to this)

I don’t really see the huge gain from a CSRF attack, could you possibly provide an example that would truly open our eyes to how “powerful” it seems to be?

One thing that kind of turns me off is that it requires social engineering in most cases.

yes man, but there are so many situations where CSRF can be used without social engineering. You are right that these types of attacks are not targeted, but you can hit a lot of random web users by spawning splogs for example. That’s why the WEB is the perfect medium for spreading worms.