Hot answers tagged csrf
20
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 ...
14
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 ...
13
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, ...
13
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 ...
12
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
...
11
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 ...
11
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
The basics
First, I assume you get 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 has is vulnerable, your question is specifically about ID in URL, so I will not discuss that further.
...
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
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.
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 ...
8
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
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
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. ...
6
Django refuses all POST requests
Only with the csrf mechanism enabled. Django issues csrf cookies in two cases:
If you're using the csrf middleware in settings.py. Middleware applies to all requests as per the WSGI spec.
If you decorate individual views with @csrf_protect, without the middleware
In the case of 1, all views are protected via this ...
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
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 ...
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 ...
5
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 ...
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
What is the implication of verifying it? The referer header:
can be spoofed by the client
can be completely omitted by the client (notoriously when going through TOR/proxies)
is no guarantee that the user actually came from there
There referer header is sent as a courtesy from your browser, it is not a HTTP RFC requirement. See here for details on the ...
4
It is difficult to execute a successfull CSRF attack on an application using viewstate but not impossible. One way to do a succcessful CSRF attack on an application with _viewstate is
Attacker is able to login to the application ( using own or aquired credentials)
Visit the page (with most common or most useful variable states) against which she wants to ...
4
Removing CSRF protection completely means that you cannot trust logging information to show the real source of a request (e. g. IP-address). This may be okay in your case.
An alternative is to add some random information to a hidden field.
Then concatenate this information with a secret string, that is only known to the server. The hash can be used as a ...
4
I usually recommend all exceptions and errors show a standard error page, and it should not reveal why the error/exception happened - or what the error was. Log the error, and give the user the log transaction number.
The reason I wouldn't reveal what happened, i.e. this action was refused due to a potential CSRF-attack, is that the attacker gain ...
4
A CAPTCHA would not be defeatable as an XSRF mitigation except by brute force, or another type of attack (eg clickjacking to frame the target site's UI in a redressing context). Image analysis could not be applied because an attacker from another site doesn't have read access to the content in the CAPTCHA.
However!
One defense that developers use to ...
Only top voted, non community-wiki answers of a minimum length are eligible
