Today my friend demonstrated such a attack.

I am using RenRen, a social networking website in a way very like Facebook in China. And I saw an article he wrote. Actually there is only an "image" embedded in this article, like this:

<img src="http://somesite.org/x.php" ... >

When a browser tries to request this URL, the headers of HTTP is a 302 temporarily redirect, and the destination is the logout page of RenRen, for example:


I know that allowing such an image existing in an posted article is the failure of RenRen's programmer. But instead of telling them to fix that, I want to configure my browser to against it. Some browsers like Safari, as I known, is resistant to such an attack, possibly because it does the MIME type checking. But I have not found a similar solution in Firefox, even not the right plugin. It seems that NoScript with appropriate configuration will do, but I am still not sure.

Therefore I would like to known, how to classify this kind of attacks, and how to prevent it----not only for Firefox...

  • 1
    The RemRen programmer failure isn't in allowing images, but in allowing a non-idempotent authenticated action to happen without an anti-Cross-Site-Request-Forgery measure. logout.do should only work off a POST request with an anti-XSRF token. It's a simple and common webapp security hole which can't really be prevented easily on the client side short of disabling all cross-site linking capability (which breaks the web pretty bad). If it doesn't work on Safari that's more likely an unrelated bug than a specific security measure.
    – bobince
    Commented Aug 20, 2013 at 12:59

4 Answers 4


You cannot defend proactively against this class of attacks. Consider:

  • the source file contains a http URL.

    • You cannot tell whether it is malicious or not.
    • You don't want to prevent it from being loaded (it would block the attack - but would also make several legitimate image repository sites worthless).
  • you then have to request that URL.

    • the logout action is activated upon request, so when the browser receives a HTTP/200 OK text/html page saying "You have been successfully logged out", even if it refuses to display it, the command has already completed.

You can organize things so that the attack fails, though.

You could purge all session identifiers from any request as soon as you hit a Redirect, so that the logout page does no longer recognize you. This might be doable with a Firefox extension. This way, you would have:

lucifer -> renren:   get me the message
renren  -> lucifer:  there is an image here
lucifer(*) -> somesite: get me the image
somesite-> lucifer:  go to renren/logout
(the request thread drops the cookie jar and becomes anonymous)
anonymous->renren:   get me the logout
renren->anonymous:   logout who? Error. Cannot logout.
(the request thread expires)

(*) actually your cookie ID with renren is not sent to somesite, since it is likely in another domain.

This could lead to malfunctions in some AJAX applications and possibly OAuth implementations, though; I'd need to check this out.


Such a type of attack is, to the extent of my knowledge, classified as a CSRF (Cross-Site Request Forgery) attack and can, in general, not be defended against.

I don't know of a way to configure Firefox to block those kinds of attacks, but there is (as you said) NoScript, which comes with a nice feature, ABE (Application Boundaries Enforcer) that allows you to specify which websites may access which other sites.

You can configure ABE via Settings -> Advanced -> ABE. There you can select the ruleset USER, where you can define the rules you want to be enforced.

An example for blocking all accesses that try to include (<img>, <script> ...) resources from renren.com and all sub-sites, that didn't originate at renren.com or a sub-site:

Site .renren.com
Accept from .renren.com

One disadvantage of that way is, that, if renren.com provides means for embedding images into other websites, that would be blocked as well, but that could probably be fixed by using Anonymize, for that purpose. On the other side, if you want to be even more restrictive, you can leave out INCLUSION, which will result in even blocking links and redirects in links you clicked on.

The difference between the Deny and Anonymize actions is, that the Deny action completely blocks the request while the Anonymize action strips the Authorization-header and the Cookie-header and turns all requests other than GET (i.e. POST, HEAD, PUT...) into data-less GET requests. The result of that is, that the website can (usually) not associate the request with a session, and /logout.do cannot terminate the session, because it doesn't know which session it would have to end, but pictures embedded into other websites that don't require a session to work will show up. A disadvantage of the Anonymize action is, that it doesn't ever show an information bar that NoScript has anonymized the request, but it silently anonymizes it, so if you are using Anonymize and something doesn't work as it should, try using Deny, which will show an information bar at the top of the screen if it blocks something.

If you are using a different service for logging into renren.com such as MSN, 360.cn, 189.cn or Baidu (listed in the order of appearance on renren.com), then, with only blocking INCLUSION it might (rather unlikely) be that you have to put an Accept clause (example: Accept from openapi.baidu.com) for the corresponding site too, if you block everything then you will have to put one in the ruleset.

More information about ABE is available here.


This is a Cross-Site Request Forgery (CSRF) vulnerability on the www.renren.com website. They should have implemented the logout.do page to only logout the user when a POST requst is made containing a token in the payload which they validate to ensure the logout request came from a user on their own site.

This should be controllable by you by disabling Third-Party Cookies. When you disable 3rd party cookies in Chrome it will prevent the 3rd party domain from reading the cookie, so the www.renren.com/logout.do page will not be able to log you out unless it is requested in a new window or tab. I have not been able to find a clear answer whether Firefox allows reading of third party cookies when accept third party cookies is set to disabled, but you could try this and see if the <img src="http://example.org/x.php" /> exploit then fails.


Add somesite.org

To your hosts file, or block it at the firewall, or on the proxy.

  • 2
    So only after an attack is detected can I block the attacker? Commented Aug 20, 2013 at 11:05
  • @LuciferOrichalcum - or you could use a whitelist approach instead, if you like this method Commented Aug 12, 2014 at 17:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .