OWASP defines Cross-Site Request Forgery (CSRF) as

an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.

(emphasis mine)

An example of attack is the link http://example.com/logout sent to an authenticated user who, upon clicking it, is logged out. We managed to change the state of the system (in that case - user login) by making the user click on a link we provided him.

Now imagine a voting system where everyone can vote, no matter whether they are authenticated or not. The system does not keep track of who voted (which is on itself obviously an issue).

I can replay without limitations HTTP calls which will increase the voting counter. Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

My opinion is that this is not a CSRF because:

  • we lack the "authenticated" part of the definition (that would be for the semantics)
  • I believe that the intent of this classification was to highlight that an attacker can make you execute commands he otherwise could not do (because you need to be authenticated). The case of the non-authenticated vote above is IMO better described by A4 (Broken Access Control)
  • Why send the link to someone else instead of hitting the link 1000 times yourself? If the last one does not work because of restrictions based on IP address, cookie based checks or similar then you have some kind of authentication, even if it is a very weak one. If there are no such checks then you don't need the cross-site part of the attack and thus I would not consider it CSRF. – Steffen Ullrich Apr 22 '17 at 11:15
  • @SteffenUllrich: "who" voted is not tracked (which, again, is a problem on its own). As I mentioned, I can replay the call indefinitely. I built this example to get advice on the nature of the vuln, specifically if being tricked into executing a link which changes something (the counter in my case) is still a CSRF, despite a lack of authentication; or is just a semantics discussion. – WoJ Apr 22 '17 at 11:18
  • From my understanding the attack does not need to be cross-site and the result does not change if it is done cross-site or same-site. Thus I would not consider it a cross-site attack. – Steffen Ullrich Apr 22 '17 at 11:25
  • does it really matter what it's called? some of these terms are not super-specific... – dandavis Apr 22 '17 at 16:43

Would sending that replay link to someone else who would (without being logged in) click on it and increase the voting counter be considered as an CSRF vulnerability?

Checking the 2013 OWASP entry on CSRF, their attack scenario (to my mind) seems to describe something similar to your example:

The application allows a user to submit a state changing request that does not include anything secret. So, the attacker constructs a request that will transfer money from the victim’s account to the attacker’s account, and then embeds this attack in an image request or iframe stored on various sites under the attacker’s control

In the case of your example, because no authentication is required, that scenario holds true in all cases: an attacker can cause a user to issue a request against your site, which will cause a state change.

I think OWASP's mention of the session being authenticated reflects an assumption on their part about what would be required to effect state changes on a site. I don't think the authentication is in fact part of the definition of CSRF - the wikipedia entry on CSRF mentions:

CSRF commonly has the following characteristics:

  • It involves sites that rely on a user's identity.
  • It exploits the site's trust in that identity.
  • It tricks the user's browser into sending HTTP requests to a target site.
  • It involves HTTP requests that have side effects.

So I think you could in fact consider your application to be vulnerable to CSRF: a user can be compelled to issue a request with side effects, and that request will always succeed (and could, at least in theory, be tied to the user's IP, for example).

I am not sure CSRF is purely about allowing an attacker to 'do something they could not otherwise' - I think one could argue it is about making a user do something they may not have done otherwise.

  • Your last sentence was actually the core of the discussion I had on that subject. This said, the first two characteristics of the Wikipedia definition are not valid in the example scenario in my question. – WoJ Apr 22 '17 at 11:53
  • In my opinion an important part of CSRF is the cross-site. This means the request should result in a different state change when done cross-site compared to same-site (i.e. on the attackers machine). Since in the example in the question the effects are the same for cross-site and same-site since no kind if user tracking is done (not by IP address, not by cookie...) I don't think that this should count as a CSRF attack. – Steffen Ullrich Apr 22 '17 at 12:21
  • @SteffenUllrich: I, on the other hand, think the "cross site" part is what is misleading in the name. The core of the attack is that one can make a call "out of the blue" and the call goes through. There is no cross anything - the call is done by the user on its own data, albeit unwillingly. The system allowed a page which was not generated by itself (and then provided to the legitimate user) to be ran. You could run a CSRF attack on yourself, from your machine (same-site, as you call it), and it would go though as well. – WoJ Apr 22 '17 at 16:49
  • Of course, it should be cross site to qualify for CSRF. Again, it is not necessary that the victim should be authenticated. But most of the real time scenarios, generally, reflects that an authenticated user gets tricked into performing some unintended action. In the beginning, even Logout CSRF was considered to be a valid issue but now it falls under exclusions. It is CSRF as the attacker is still able to cause the state change(performed cross site) and the unintended action has been done on his/her behalf. Although the impact is not considerable but it still falls under CSRF. – mud1t Apr 22 '17 at 16:59
  • @WoJ: the main idea behind CSRF is that an attacker can trigger an action using a cross-site request which he can not trigger using a direct request from the attackers system. This commonly means that the attack is successful because it is implicitly authenticated by the attacked user via cookie or IP address, i.e. with properties the attacker does not know or can not emulate from its own system. But it can also be a request from the victim to a system internal to the victim which cannot be reached from outside (i.e. from the attacker) even if no authentication is involved. – Steffen Ullrich Apr 22 '17 at 17:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.