Persistent CSRF and The Hotlink Hell
When we talk about CSRF we often assume that there is one kind only. After all, what else is in there when CSRF is all about making GET or POST requests on behalf of the victim? The victim needs to visit a page which launches the CSRF exploit. If the victim happens to have an established session with the exploited application, the attacker can perform the desired action like resetting the login credentials, for example.
However, CSRF can be as persistent as Persistent XSS (Cross-site Scripting) is and you don't need XSS to support it. Before delving into persistent CSRF's issues we need to look at a few other things that brought the idea on first place.
Hotlinking is the placing of a linked object, often an image, from one site into a web page belonging to a second site. The second site is said to have an inline link to the site where the object is located. Inline linking is also known as hotlinking, leeching, direct linking or bandwidth theft. Wikipedia
Those who have been active on the web for long enough probably know about what hotlinks are and how they have been abused to steal bandwidth. There is more into that however. Every time someone hotlinks, they instantly create a persistent CSRF hole. Here is how, as explained by a case study:
This simple example outlines the entire idea behind persistent CSRF. If you think that many applications are vulnerable to non-persistent CSRF, there are even more vulnerable to the persistent kind given that everyone today hotlinks in one way or another.
Web2.0 Mashups developers, in particular, needs to be very concious with persistent CSRF attacks. The whole idea behind Web2.0/3.0 (Semantic Web) is that people can share the same data while providing different interfaces which use the information in different ways. This is great in theory, but every time someone renders an image element, that is not inspected, a CSRF hole is left wide open. Let's take for example the popular Google Reader, my favourite online application. Google Reader, allows you to read feeds. These feeds can contain images, podcasts and screencasts. However, if any of these feeds contain an image that points to https://www.google.com/accounts/Logout?nui=1&service=reader&continue=http%3A%2F%2Fwww.google.com%2Freader%2F like this:
<img src="https://www.google.com/accounts/Logout?nui=1&service=reader&continue=http%3A%2F%2Fwww.google.com%2Freader%2F"/>... upon previewing the feed, the user is automatically de-authenticated before having time to react. Everything will happen in the background. Moreover, the vector is persistent. The next time the user visits the malicious feed, they will be de-authenticated again.
Keep in mind that all I am demonstrating here is a CSRF that is mostly annoying rather then dangerous.
Archived Comments
Wladimir Palant
If you think that many applications are vulnerable to non-persistent CSRF, there are even more vulnerable to the persistent kind. - PDPI 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
bob.com/action.php?logoutbob.com/action.php?trylogoutbob.com/action.php?trylogout&token=randomjunktoken=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?
<script type="text/javascript" src="http://example.com?updateInfo.asp?name=John&callback=myFunc">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.
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.
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 medium to high risk. The same thing should apply to persistent CSRF imho.
