Tag Info

Hot answers tagged

34

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 ...


25

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 ...


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

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

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, ...


14

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 ...


14

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. ...


14

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 ...


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

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 ...


12

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 ...


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

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 ...


9

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 ...


9

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 ...


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

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 ...


8

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 ...


8

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 ...


7

Neither is necessarily more secure, but I will give you some opinions and perhaps facts. Host-extract can determine hostnames, which is also possible via virtual host enumeration. DirBuster, skipfish, and fuzzdb can rely on forced browsing, directory indexes, and predictable resource locations to find vulnerable directory structures and other issues. ...


7

CSRF or Cross-Site Request Forgery is basically a bad person tricking a good person's browser into performing functions on your website on the bad persons behalf. Here is an example: Good user logs into your website and obtains a valid session Bad user tricks good user into following a link to a malicious site Malicious site contains a ...


7

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 ...


7

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 ...


7

The Same-Origin Policy makes it impossible for JavaScript on A.com to read content from B.com. However, Same-Origin Policy does not prevent JavaScript or HTML on A.com from sending an arbitrary request to B.com. In order to prevent this, you need a method of CSRF Prevention, such as a secret token which would not work if the system wasn't blind. The ...


7

A few other factors which contribute to the need for so much entropy and why they might suggest 30 characters: Firstly, this is to protect the application side login action – which will then create its own authenticated session independent of the Google one. The important thing is that it's up to the application to store the token and decide when to stop ...


6

First off: This is absolutely the wrong way to solve CSRF problems. CSRF vulnerabilities are a problem in your site, not in the browser. Blacklisting certain browsers is not going to solve your CSRF vulnerabilities. CSRF is not browser-specific and cannot be prevented through browser blacklisting. Detecting browser versions: There are various ways to ...


6

There is at least one security benefit of sub-domains. If there is an XSS vulnerability on enroll.mydomain.net it can't be used to hijack a session on admin.mydomain.net. This is due to the Same-Origin Policy. It would also make it easier to move that application to a different server if need be. Isolation of failure is a good Defense in Depth approach. ...


6

When you log in to example.com, your browser stores a session token in a cookie. This session token uniquely identifies your logged-in session with example.com. Every time your browser makes any request to example.com, that request includes your example.com cookie data, including your unique session token. With that in mind, consider the fact that a Web ...



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