0

I have been reading up on CSRF/XSRF a bit and a lot of it seems to talk about cookies as they can be involved in logging the user back in automatically.

So I was just wondering if your site doesn't use cookies, do you still need to worry about using it or do you need to worry about using it on public accessible forms?

I assume you still do as the user could already be logged in within the browser and then they could be exposed to it.

As for public forms, obviously the only reason you would want protection on these is if you didn't want remote sites posting to them correct!?

Sam
  • 7,252
  • 16
  • 46
  • 65
Brett
  • 19,449
  • 54
  • 157
  • 290

2 Answers2

1

Cross-Site-Request-Forgery, CSRF, isn't an attack directed to cookie-implementing sites, it's an attack that involves the ability to cause a user's browser visiting site A to invoke an action on site B - normally one in which they have to log in to access, but it isn't necessary.

For instance, assume you have a simple "Contact Us" form on Site B. This form is publicly accessible and requires no user-login. If Site A can submit this form from a client's browser via javascript (or Flash, etc.) - then this would be considered CSRF as the "Contact Us" form will appear to have originated from the end-user who never actually visited Site B.

Now, this attack is far more dangerous when actions are more complex than a simple "Contact Us" form, say, "Transfer money from account X to account Y". These actions generally require a user to be logged in to the site, which also normally use a cookie of some form (Session IDs are sent back and forth from the browser to the server as cookies). Without CSRF protection (such as tokens), the "Transfer" action could be performed as long as the user has an actively opened session. If, however, the site actually saves a cookie to allow a "Remember Me" function where the user doesn't need to submit their credentials each time, the CSRF should be able to submit without the user having an active session as well.

newfurniturey
  • 37,556
  • 9
  • 94
  • 102
1

Cross-Site Request Forgery is an issue when any state is maintained at the client side and submitted without user approval.

The most common example of state used for authentication is indeed a HTTP cookie, but others exist:

  • HTTP Authentication: Basic Auth, Digest Auth or Integrated Windows Authentication; Basic Auth is often used on router admin interfaces, many of which are vulnerable to CSRF.

  • HTTPS client certificate;

  • marginal issues like use of client IP address, HTTPS session ID, or User-Agent as a non-reliable part of an authentication acceptance decision.

If any of these are used without a verifiably server-issued token in the submission body that is tied to the principal involved, then you've got a CSRF problem.

If you don't have any concept of authentication, having only public-facing forms, then you don't really have CSRF as such: user A persuading user B to post a publicly-available form doesn't count as a Forgery if the site is doing nothing to distinguish a submission from user A from one from user B anyway.

However, an open public form without any server-issued token of some form in it would be more vulnerable to DDoS attacks: instead of DoS-attacking the form themselves, an attacker could make a site that pushed anyone who visited it into submitting the form. This amplifies the attack and makes it harder to block as it comes from many sources. Tokens can also be useful as a defence against simplistic form spammer bots. These aren't CSRF issues but they can be mitigated with the same kinds of defence.

bobince
  • 528,062
  • 107
  • 651
  • 834