Hot answers tagged

51

Yes, it is important to include anti-forgery tokens for login pages. Why? Because of the potential for "login CSRF" attacks. In a login CSRF attack, the attacker logs the victim into the target site with the attacker's account. Consider, for instance, an attack on Alice, who is a user of Paypal, by an evil attacker Evelyn. If Paypal didn't protect its ...


47

SQL injection. If you use Django's object-relational mapper (ORM) layer, you are basically protected from SQL injection. The only caveat is that you need to avoid manually forming SQL queries using string concatenation. For instance, do not use raw SQL queries (e.g., raw()). Similarly, do not use the extra() method/modifier to inject raw SQL. Do not ...


45

For the reasons already discussed, it is not necessary to generate a new token per request. It brings almost zero security advantage, and it costs you in terms of usability: with only one token valid at once, the user will not be able to navigate the webapp normally. For example if they hit the 'back' button and submit the form with new values, the ...


19

The best way to build CSRF protection properly: Don't. Most common frameworks have this protection already built in (ASP.NET, Struts, Ruby I think), or there are existing libraries that have already been vetted. (e.g. OWASP's CSRFGuard). Another option, depending on your context, is to enforce reauthentication of the user, but only for specific, ...


19

The basics First, I assume you understand the most basic session ID security right: you are using an ID with sufficient entropy, and you use transport level security (HTTPS). Any approach to session ID (URL, cookies, whatever) that does not get those right is vulnerable, your question is specifically about ID in URL, so I will not discuss that further. ...


18

There is a good explanation on OWASP: OWASP CSRF Prevention Cheat Sheet In short they say that there are two ways: Add a random token to each user session. Only if this token is present and correct will the changes be applied, otherwise the request should be rejected. It is important that the token is only sent with a POST request, since GET requests can ...


18

Yes you should protect against Login CSRF. Without this protection an attacker can effectively reverse a CSRF attack. Rather than the victim being logged in to their own account and the attacker tries to ride the session by making requests to the site using the victim's cookies, they will be logging into the site under the attacker's credentials allowing the ...


17

Your question makes an assumption that should not be made in the field: wouldn't you be able to detect and lock them out after a few attempts Yes, in a good working environment there should be a system like this in place that rate-limits failures of various kinds. This is a good thing to do but it should never your first or only line of defense. If ...


16

You must at the very least check for Content-Type: application/json on the request. It's not possible to get a POSTed <form> to submit a request with Content-Type: application/json. But you can submit a form with a valid JSON structure in the body as enctype="text/plain". It's not possible to do a cross-origin (CORS) XMLHttpRequest POST with ...


16

Short answer: To prevent brute forcing the CSRF token. Let's take a trivial example: let's say your token is a single digit, accepting values from 0 to 9. Now sure, an attacker cannot read this value from the cookie or header, but she does not have to - she can just have the attack send 10 CSRF requests, one with each possible value. One of them will be ...


15

Quoted from OWASP's CSRF Prevention page: Double Submit Cookies Double submitting cookies is defined as sending the session ID cookie in two different ways for every form request. First as a traditional header value, and again as a hidden form value. When a user visits a site, the site should generate a (cryptographically strong) pseudorandom value ...


15

If I understand you correctly, you are saying why is the browser blocking access to a resource that can be freely obtained over the internet if cookies are not involved? Well consider this scenario: www.evil.com - contains malicious script code looking to exploit CSRF vulnerabilites. www.privatesite.com - this is your external site, but instead of locking ...


15

SSL Connection to the server so no one can sniff passphrases or data over the network. Don't forget your backup: it should be encrypted too. The key should be stored independently so if someone gains access to the backup he cannot use the data. Depending on your country of residence there can be legal requirements for health data protection. Manage access ...


14

The purpose of ASP.NET ViewState is to persist control state between post-backs (See http://msdn.microsoft.com/en-us/library/ms972976.aspx), it does not implicitly enable security that would prevent CSRF. Also note that encrypted ViewState in unpatched older versions of ASP.NET are susceptible to an encryption vulnerability see ...


14

Security is about defence in depth. Simply checking the value is sufficient at the moment, but future technologies and attacks may be leveraged to break your protection. Testing for the presence of a token achieves the absolute minimum defence necessary to deal with current attacks. Adding the random token improves the security against potential future ...


14

Simple. You read the anti-CSRF token from the newly requested login page and each time the token is attached to the server's response. In this case, before you submit a POST request, you first read the response to your GET request from the server and the new token will be attached to it. Then you use it to generate new brute-force POST request. There may be ...


13

Ajax is just pasing data over HTTP - it's not magic - so you secure it in exactly the same way you do with your normal webpages - check for authentication and authorization Encrypt or add salted hash checks to data exported to the browser for resubmission treat any data received in the request as potentially dangerous use HTTPS where its appropriate ...


13

Overview. The standard advice is to use a unique CSRF token that is unique for each request. Why? Because a per-request token is a bit more resilient to certain kinds of implementation errors than a per-session token. This makes per-request tokens arguably the best choice for new web application development. Also, no security auditor is going to hassle ...


12

With anonymous cookies If you are happy to generate secure tokens which are set as anonymous users' cookies, but not to store them server side then you could simply double submit cookies. e.g. Legitimate user: Anon user navigates to the login page, receives cookie which is sent to the browser. Anon user logs in and the browser sends the cookie as a ...


11

If the transaction has any side effects, yes, you should set up your web server so it does not process those GET requests. You should not allow any GET request to cause side effects on your server. I can't point to any particular attack that will necessarily cause problems for you, but there are subtle vulnerabilities if you allow processing of a GET ...


11

Django is using a Double-Submit Cookie and it is accepted as a safe method of CSRF prevention. Why? Because, It is impossible for an attacker to control the cookie filed in a CSRF attack. A CSRF attack is relying on the fact the browser manages cookies, and will include cookies associated with a target domain to the forged HTTP request. It is possible to ...


11

The request can still be sent, just not read: Cross-origin writes are typically allowed. Examples are links, redirects and form sumissions [sic]. Cross-origin reads are typically not allowed. So only the reading of the response is protected by the Same Origin Policy, not the making of the request itself, although only certain headers can be ...


10

This is probably a bad mechanism, since it violates Kerckhoff's principle. If an attacker knows how your "encryption" works, he can just encrypt his own CSRF blob for a specific user and use it in targeted attacks. CSRF leverages the fact that your browser will send a cookie containing a session ID that authenticates you to the server, even if the request ...


10

No because you should never allow scripts to be able to access your cookies. Refer to HTTPOnly on the OWASP website. To prevent people from being able to steal session id's, should XSS be present, you should always set this cookie flag. Your mechanism would not work anymore as it would not be able to access the cookie.


9

There are a number of reasons for using POST: The browser warns on re-submission. The size of the content is not restricted File upload only works via POST Some programs speed up response time by prefetching linked pages, so trigger bogus request. The URL cannot be bookmarked, preventing accidental submission (though the CSRF token may be time-limited ...


9

I wouldn't rely on this design. The HTTP specification states: Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others. In particular, the ...


9

XSS can be used to read a CSRF token, even if it is a single submit token, that is child's play. Its likely that this recommendation of a single submit token came from someone who doesn't understand CSRF. The only reason to use a "single submit token" is if you want to prevent the user from accidentally clicking submit twice. A good use of this is to ...


9

A summary of how CSRF attacks work goes like this: You, the good user, while logged into a web site A, visit some other site's page B. That page does a GET (can be a POST, a little more complex to set up) to a page X on site A (which you are logged in to), with e.g. . Your browser obliges, using your already authenticated session/cookie Page X by design ...


9

RESTful services are "stateless", except when it comes to authentication. Authentication is a state that cannot be avoided and so it is allowed in a RESTful design. In RESTful services, this state is often implemented as a authentication token or in the case of OAuth: an authentication-bearer token. This token should be unknown to the attacker and is ...



Only top voted, non community-wiki answers of a minimum length are eligible