Consider the picture below (taken from page 21 here). Is this possible? If so, how can I prevent it?

enter image description here

  • It's a rather strange example but it would be feasible if Google didn't have CSRF protection. @GBC has already mentioned more common ways of using CSRF such as the attacker causing an already logged-in admin to perform an action that's restricted to admins.
    – Ladadadada
    Commented Mar 13, 2013 at 8:38
  • 1
    This slide is from a lecture from a class at Stanford taught by Collin Jackson, and yes it's possible. If you're familiar with the web security community, you may know that Collin Jackson is one of the pioneers. Also, for what it's worth: those Stanford instructors aren't exactly dumb; if they're teaching their undergraduates this is possible, there's a decent chance they have a good reason for that.
    – D.W.
    Commented Mar 13, 2013 at 9:00
  • My concern is about user, how user can detect that an attacker used his (attacker's) credentials, also, how browser include the cookie for next requests, because the cookies are considered third party...
    – Akam
    Commented Mar 13, 2013 at 9:53
  • 1
    If you ask "how to prevent it", do you mean how can the victim prevent this, or how can the target-system (google in this example) prevent this? If it is about the victim (supposing the traget doesn't prevent it or we do not know) the sollutions would be more difficult (I can only think of browsing more security aware, so not allowing automatic posts without intervention, maybe even blocking scripts), so I'd say the 'target-system' part might be more interesting?
    – Nanne
    Commented Mar 13, 2013 at 11:05
  • @Nanne: is there any tools or mechanism that user can implement it to be sure about each navigation in the Browser? the target system might change, however, users are still there for different systems...
    – Akam
    Commented Mar 13, 2013 at 11:07

2 Answers 2


Yes, it's possible. Or rather, it would be possible, except that Google has deployed countermeasures to defend against precisely this attack.

This attack is known as "login CSRF". It's similar to a standard CSRF attack, but a little different. If you search on "login CSRF", you will find information on the attack. It is a real threat against some web services. For more details, see my answer to a related question, and the following research paper:

See especially Sections 1-3 of that research paper for more technical details. The paper describes how to defend against the attack.

The short version of how to defend against the attack is that you include a secret CSRF token in all POST requests, including login attempts; and on the server side, you require that login attempts have the proper secret CSRF token included. OWASP has more on how to deploy secret CSRF tokens.

  • dose browser distinguishes between third party cookie and normal cookie? because at this case, the cookie should be considered third part, and when user visits the site (here is google) dose browser include it as normal cookie? (this is just assumptions)
    – Akam
    Commented Mar 13, 2013 at 9:56

The goal of a CSRF attack isn't usually to steal credentials, or to log in though stolen details, but to get a valid account to perform an action chosen by the attacker. For example, if an administrator of a target site were victim of an CSRF attack, they may elevate a non-admin account to an admin account without realizing it.

This can either happen through an XSS flaw on the target site itself, or the administrator could be tricked into visiting a malicious website that executes a command against the target site (as shown in the image above). Or the administrator could have been tricked into visiting their own site directly, for example: http://somesite.com/edit_user.php?action=setClass&class=admin&userId=23443 (not sure if this counts as CSRF still, or if it's just social engineering).

To protect against this you can use CAPTCHAS on pages that perform important actions, or you can use secret hash codes to attempt to verify that a request is wanted.

There's a good description and suggestions for countermeasures here: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

  • 1
    This answer has a bunch of errors. You're talking about an ordinary CSRF, but this is a different kind of attack: it involves logging in the victim, using the attacker's account. That doesn't allow elevating a non-admin account to an admin account. This attack (login CSRF) has nothing to do with XSS. Login CSRF can cause harm in certain special scenarios (maybe not the usual case, but it does apply to some web sites). It is known as login CSRF, and it is different from standard CSRF (and different from XSS). CAPTCHAs are neither necessary nor sufficient to defend against login CSRF.
    – D.W.
    Commented Mar 13, 2013 at 9:05
  • Interesting. I'd never heard of it - my apologies!
    – GBC
    Commented Mar 13, 2013 at 10:24

You must log in to answer this question.

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