An application is ‘vulnerable’ to CSRF by just working in a browser. This is simply a fact of life of the architecture of HTTP and browsers. Cookies will be sent by the browser when it makes requests. Period. Maybe the browser tries to limit the requests it makes, but when it makes them, if it has cookies, they will be sent. There is nothing an application can do to prevent this.

An application may have serious CSRF vulnerabilities if it allows for any type of state change to happen without taking some kind of precautions - like including a nonce, captcha, or some other device designed to make sure that the legitamate user actually is the one initiating these requests.

What you describe is a persistent vector for CSRF. Just because I can send your browser to a URL, does not mean that the URL will do anything. It is independent of the actual CSRF problem that will be exploited.

In persistent XSS, if you fix the problem by using proper input validation or output encoding, then you have fixed the problem. With persistent CSRF (as you call it), both the vector (the image src that is under an attackers control) and the actual CSRF vuln (the request that gets submitted) need to be fixed independently.

The interesting thing is that the commercial web application scanners have recently started looking for places where they can control the source of an image tag, and they call any such situation “CSRF”. I disagree, for the reasons stated above. It is simply a vector through which CSRF -may- be exploited. By itself, however, it is not a CSRF vulnerability. It is a ‘force the user’s browser to do a GET’ vulnerability. They are not the same thing.

That does NOT mean that the server side is more vulnerable as you stated.

of course it is more vulnerable. Think about it, the attacker does not need to social engineer the user every time the need to do something. The attack will happen on its own.

Usually persistent XSS is rated as high risk. The same thing applies to persistent CSRF.

Quoting pdp

If you think that many applications are vulnerable to non-persistent CSRF, there are even more vulnerable to the persistent kind.

again

we find persistent XSS a lot more dangerous then non-persistent XSS. The same thing is applicable to CSRF. What is so confusing about it?

It simply means the attacker has a longer opportunity to launch the attack. This is NO different than if I embedded an img tag into a website. I’m not taking advantage of a persistent CSRF vuln in the site, I’m making the vector in which I launch the CSRF vuln persistent. One of the reasons I’ve chimed in is that the statement is inaccurate.

I don’t agree. There are a persistent and non-persistent CSRF vectors. What is persistency first of all? Isn’t persistent XSS a vector that reoccurs every time a user arrives on a given web resource? The same is applicable to CSRF too.

For example, the POC that I provided for Google Reader is persistent because every time the user visits the feed the exploit will be launched. IMHO, this is a persistent CSRF.

usually we make differentiations between persistent and non-persistent XSS. Usually, we find persistent XSS a lot more dangerous then non-persistent XSS. The same thing is applicable to CSRF. What is so confusing about it?

CSRF isn’t persistent verses non persistent like you are stating. It is a server side logical flaw PERIOD. It is exploited/triggered by a client side request.

The way the request is embedded into the client may be via persistent/non persistent XSS, however it isn’t persistent/non persistent CSRF.

Lucky,
you are right but GET is easier to handle. For example, look how JSON and On-demand JavaScript operate:

<script type="text/javascript" src="http://example.com?updateInfo.asp?name=John&callback=myFunc">

the script above will update the name to John and return the updated record. Expect to see more of these REST interfaces.

Anonymous Coward,
thanks

santa claus,
thanks

bob.com/action.php?logout

Would be replaced with this page:

bob.com/action.php?trylogout

Which dynamically creates a new link to actually logout:

bob.com/action.php?trylogout&token=randomjunk

If there’s no token=randomjunk, trylogout flops.

If I understand this attack correctly (I’m fairly new at web application security), then the intermediary page prevents the attack. Do you concur?

Not that it would be bulletproof, but it makes the attackers work a little harder.

Today Persistent CSRF and The Hotlink Hell article about hotlinking and CSRF issues.

From GNUCitizen’s post
It is not GoogleÂ’s fault. I am not sure what exactly needs to be done in order to fight against this type of attacks.

First of …

If you think that many applications are vulnerable to non-persistent CSRF, there are even more vulnerable to the persistent kind. - PDP

I think you are confused in this sentence. An application vulnerable to CSRF is vulnerable regardless of the vector. The way in which the request is triggered to the vulnerable application has nothing to do being more or less vulnerable for persistent or non persistent.

Regarding the RSS vector this was also discussed in my blackhat talk and whitepaper as a great CSRF vector.

Paper
http://www.cgisecurity.com/papers/HackingFeeds.pdf

Blackhat Slides
http://www.cgisecurity.com/papers/RSS-Security.ppt

If attackers compromise a machine that serves a lot hotlinks they will be able to create a massive botnet almost instantly. Now, this is not very nice if you think about it. Also, I am almost sure that in the future you will see stuff like Hotlink BOTNETs where the attackers themselves persuade users to use hotlinks from their controlled servers.

That of course, is just a speculations and nothing else.