Tag Info

Hot answers tagged

29

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


21

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


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


15

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


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

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


13

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


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

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

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


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


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

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


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


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

Yes, it does make sense. HTTPS does nothing to protect you against CSRF attacks. You would carry out an CSRF attack like you would against a HTTP enabled website. Take a look at the CSRF description from OWASP to understand how it works. It will be obvious that the encryption of the communication channel is irrelevant for this type of attack.


6

Yes. You want Brakeman, a tool that scans your RoR code for security vulnerabilities I recommend reading the OWASP Ruby on Rails Security Guide. You could also try any web pen-testing tool; they are not language-specific. There are many of them. They only find low-hanging fruit, not all security problems, but it can't hurt to use them just in case they ...


6

I suggest that you read the OWASP references on this topic, including: Cross-Site Request Forgery (CSRF) Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet Testing for CSRF (OWASP-SM-005) Reviewing code for Cross-Site Request Forgery issues as well as the following resources: OWASP Top 10 for .NET developers part 5: Cross-Site Request Forgery ...


6

A CSRF attack tries to exploit "the trust that a site has in a user's browser" (so says the Wikipedia page, and it is well said). It is about the server accepting a request from the client, on virtue of the request coming with some authentication characteristic which makes the server believe that it comes from the genuine user (which it does) and under the ...


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


5

The threats with AJAX are the same that are faced with normal web request: XSS, SQL Injection, etc. One thing to note is that with AJAX, if you load data from a untrusted source (for example some webservice), you should also validate that data on the client, not just on the server, or else someone can potentially inject javascript and other nasty things. ...


5

Ahh! I think I can explain. foo.com can navigate the browser to any page or domain. Thus, foo.com can submit a form that posts to localhost, even though that's a different domain. No problem. After navigating to a new page, the browser will happily display the contents of the new page to the user. For instance, after submitting the form to localhost, ...



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