5

I have gone through the example of CSRF funds transfer from a bank where the user is logged in. Similarly I have looked at CSRF in case of email updating. I think I understood it but I am not quite sure if it extends to unauthenticated requests/ form submissions as well. I am now trying to figure out the impact of CSRF particularly in reference to given below context.

Suppose a shopping website where both authenticated and unauthenticated users can browse and shop. Imagine a scenario where an unauthenticated user browsers and adds a item to his cart(still unauthenticated). He later decides to checkout and is redirected to the checkout page without logging in(access escalated to Guest user from unauthenticated user or something similar).The user now enters his personal information(over SSL) like email, address, telephone, credit card information, etc. His shopping is complete and he closes the application. He is able track/update order using link sent to his email or order number.

  1. Since the user is/might never authenticate in this application, do All forms/requests still need to be protected against CSRF? If not, in what case CSRF protection need to be implemented?

  2. Additionally should searches be be protected against CSRF for logged in vs unauthenticated users? It would be great if you could answer for both. How about comments by visitors (not logged in)?

  3. Are referer checks required even after Tokens are used for CSRF Protection? I don't think so, still making sure.(Not particularly related to above scenario).

  4. How important is Login CSRF for E-commerce websites?

Let me know if I may have missed something here, i am still trying to fully understand CSRF, its impact and associated risks in various scenarios.

P.S. Some scanners throw CSRF at every form submission without random tokens or referer checks.

4

1.Since the user is/might never authenticate in this application, do All forms/requests still need to be protected against CSRF? If not, in what case CSRF protection need to be implemented?

If the user has some sort of confidential session state with the application, then CSRF is recommended.

You may want to protect against CSRF for adding products to the basket. However, if you don't then you may find it an acceptable risk instead to show the user their basket contents and ask them to confirm before they proceed to checkout. This way they would be aware if anything had been changed in their basket before they proceed to payment. Of course, the confirmation form itself should have CSRF protection and it should take the rest of the checkout state from the displayed form, rather than session as it could still be susceptible to attacks while the page is being displayed to the user.

2.Additionally should searches be be protected against CSRF for logged in vs unauthenticated users? It would be great if you could answer for both. How about comments by visitors(not logged in)?

You only need to protect "unsafe" requests. That is, actions on your application that change state. See RFC 7231 for details on safe requests. Unsafe requests are usually implemented via the POST method, so you should focus on protecting all POST requests rather than GET requests. This is assuming that all unsafe requests are POSTs (they should be if correctly implemented).

3.Are referer checks required even after Tokens are used for CSRF Protection? I don't think so, still making sure.(Not particularly related to above scenario).

No, token based CSRF protection replaces the weaker form of referer protection.

How important is Login CSRF for E-commerce websites?

Very important. You don't want to make your site vulnerable to attackers submitting or changing orders, personal details or passwords (particularly if they allow access to card details). Even without authentication, you still need to protect the current user's session as they place their order.

  • Excellent answer. I was going to point out the adding item to the cart as well. One issue that many web application developers sometimes seem to forget is that RFC 2616 requires all GET requests to be idempotent. A GET must not ever change state as they can be cached and repeated. If you always assume that a GET will not make it to a server more than once, and also assume that it will always get to the server two times, then you apps will behave according to spec. – COL Wotohice Apr 13 '15 at 12:08
0

While @SilverlightFox's answer to question two is correct it's not just the state change that a CSRF token protects against. Cross domain timing attacks could well reveal sensitive information within the search index (See https://www.idontplaydarts.com/2015/09/cross-domain-timing-attacks-against-lucene/ for more information).

This is why it is essential to protect even search with a CSRF token.

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.