New answers tagged csrf
-1
Looks like the simple solution (i.e., CSRF protection but with all-cacheable web resources) is to just add a separate cookie containing the anti-CSRF token but accessible to page javascript.
In other words, when the client logs in, I'll actually set two cookies (one HttpOnly sessionid and one non-HttpOnly anti-CSRF token, accessed by page scripts). So, the ...
0
Should web applications using websockets (...) include nonces verified by the server on each transmission to prevent CSRF?
TL;DR: This is desirable, though not necessarily on each trasnmission (once per connection should suffice) and not to prevent CSRF, but XSS. This is more a safeguard than a strict necessity though. Details below.
To answer ...
1
The problem with this implantation is that the CSRF token is not actually stored within an anonymous function. This token would be stored within text that declares an anonymous function. An XSS payload can request this text from the server using an XHR, the CSRF token can be read and another XHR can be used to send an arbitrary forged request.
Related: ...
2
The only time that you need to worry about the token being read is if there's a malicious extension or an MITM attack being carried out.
In both cases, it's no longer a CSRF problem. Both attacks have the capability of catching the request on the fly (after your javascript has assembled it with the token) and modifying it. This isn't CSRF, but it's still a ...
0
As mentioned by a number people - double submit is an ok CSRF protection, provided that you use a separate nonce. Using session id is very wrong in this context, starting with the fact that sessionid has to be HTTPOnly for XSS protection.
An argument of "what if there is XSS on this page/website" is not valid - when you have XSS, CSRF is the least of your ...
1
First of all, CSRF attacks do not require any JavaScript at all. You can forge arbitrary requests with pure HTML to send arbitrary GET or POST requests via simple images or simple forms.
JavaScript would only be helpful to automatically send the latter forms as are not send automatically like a request for an image would. But you could also style the form’s ...
2
Yes, they are blind. The same-origin policy prevents pages hosted in one domain using one protocol [and sometimes also port] to making arbitrary requests to a different domain/protocol. So, one attacker would not be able to make a "CSRF Ajax request" unless your server supports CORS. What makes CSRF attacks possible at all are the exceptions for the ...
4
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 ...
1
You could, but it seems a bit unwieldy to me. Any CSRF-prevention mechanism works like this:
Make the server only accept requests that satisfy some conditions
Ensure that the conditions are something that can't be forged
Write your HTML so that the requests it generates follow the conditions set by the server.
The tried-and-tested method is to use ...
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 ...
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.
1
XSS occurs when a piece of browser scripts origin from 3rd-party sources be injected into a vulnerable website's content, which can be considered as instructions to the user's browser to "present" a website. In web's terminology, the user's browser believes that such instructions are legitimate within the web site domain. In XSS scenario, the returned ...
4
Because of the same-origin policy, in the XSS case, the script needs to be loaded in the user's browser in a page on the same domain you're trying to attack.
So, to steal an example.com cookie from a user, you need to "inject" that JavaScript in a page on example.com. For example, example.com/viewArticle.php?id=4123&comments=1 where the comment section ...
Top 50 recent answers are included
