Tag Info

New answers tagged

0

The simplest way is to check for the X-Requested-With header being set. An alternative is to check the Origin for supported browsers. Alternatively, check out the other solutions on the Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. Double Submit Cookies might be appropriate here as you will not require server side state, although the ...


0

I also believe that the Double Submit Cookie pattern is discouraged because it requires setting the cookie HTTPOnly value to False It doesn't require setting HTTPOnly to false. This is only if you have some JavaScript code that will set the hidden form field value to the same as the cookie. It is possible to do this without JavaScript by simply ...


1

The answer is pretty straightforward: it doesn't. If the token is sent over cleartext then you're hosed. The spec doesn't provide mitigations for security issues that arise from not following the spec's recommendations. Alternatively there is some relief in using the code flow because you're passing a nonce of sorts (the 'code') over cleartext instead. You ...


1

Storing sensitive data in a cookie is not necessarily unsafe, it depends how you configure the cookie. Te cookie needs to be configured as a secure cookie (limited to HTTPS only), HttpOnly flag should be set to avoid cross side scripting (the cookie will not be available from javascript) and the domain must be set to the correct value depending on the scope ...


0

You are right with all those issues. That implementation is not secure and could lead to identity theft. It is even less secure than using HTTP basic authentication as those cookies are vulnerable to XSS attacks. I could not think of any other issue apart from the ones you provided. (aren't they enough?). Well, there is the id of the entry of the user in ...


0

Yes, if you want, there is no extra security risk as long as you make sure that if caching is enabled, only private caching is specified to prevent this value being cached by any proxy server between users and your system. e.g. cache-control: private HTTP response header. The Same Origin Policy will prevent the token from being read on the page (assuming ...


0

You should use tokens to prevent some "quick" spamming of your forms and requests in general. But actually the hacker can see the request with the whole query and notice that there is a token used. Once he got it he can build a spam bot using the random token your form is using. A better way to be secure would be to use, lets say 3 (or more) tokens and a ...


0

An attacker can send you a link your browser will open when you have a session in your protected application. This can happen even by showing images in an email. In this case the request from your browser contains the session cookie but not the anti-CRSF token and the server can invalidate the malicius request from the victim's browser. CSRF tokend have to ...


0

Call it that if you want - it doesn't affect the security of your system in any way. At the end of the day, you can't protect against everything. If social engineering is involved, then the scammer could simply devise a reason for the user to give them the account password directly. There are also other attacks that are difficult to defend against where ...



Top 50 recent answers are included