New answers tagged

1

When implementing CSRF protection, one generally uses a CSRF cookie that must be included in the body of the request. This prevents CSRF attacks because the malicious website cannot read the other website's cookies. This is fundamentally incorrect. I think you misunderstand the attack vector. A CSRF attack (also called "session riding") will typically ...


2

Yes, this is one possible approach to defending against CSRF. It's called the double submit cookie pattern. The synchronizer token pattern - the second token isn't stored in a cookie but server-side in the session - is a bit more common in practice though.


0

Anders answer addresses the question, but only offers the solution of storing a copy of the token in the session. It would also be possible to store the token client side as long as it is appropriately protected against replay attacks - but this has significant overlap with the problem of session hijacking.... if ($_REQUEST['token']) { if (validate($...


0

It sounds like you are worried about your web server code trusting a third party library that generates content within your HTTP response. This is a very valid concern. If all that it generates is CSRF tokens, i.e. some strings, it makes sense to add XSS protection (whitelisting chars, escaping special characters ...). This should eliminate most of the ...


1

Is the plan good? Your plan looks good to me. Using a CSRF-token is the standard solution to this kind of problem. But you should not feel safe just because some stranger on the internet tells you it looks good - make sure you understand what you are doing and why, otherwise your are bound to make mistakes. (A minor point: I am not sure you need to change ...


0

I think you are wasting your time trying to implement per request tokens. D.W. explains it in this answer: Of course, I know the argument why some people might recommend generating a new CSRF token for every request. They are thinking, if you also have a XSS vulnerability on your website, then if you use a single CSRF token per session it will be easy to ...


1

The solution used in my Web-Applications (JSF) is to tell the browser to make a new GET-Request on browser-back (or reopen tab). This is done with the following HTTP Response Header: Cache-Control: no-store, no-cache, must-revalidate Expires: [in the past] The first line is for HTTP 1.1, the second line is for Proxy-Servers. This should work (at least) in ...


3

What the code does Lets look at what the code does. import cgi import Cookie First we just need to import some libraries to be used later. c = Cookie.SimpleCookie() This stores all the cookies sent in the clients request in the variable c. form = cgi.FieldStorage() This stores all the form values sent in the clients request in the variable form. ...


0

please refer to the "Standard header checks" section on this page : https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet In my knowledge, referrer headers cannot be changed if there is no xss flaw. Ajax requests are also not allowed to change the referrer header as told by someone in comments on this thread: exploiting ...


1

Referer is considered a special header (like `Host´) and can not be set inside the browser. So the most you can do with some tricks is to make it empty, but not to point to some other side. Of course you could use some other tools to make crafted requests with your own Referer header. But in this case you (as attacker) don't have access to the cookies ...


1

Yes,it will work. The CORS header will avoid external requests from perform actions(eg. a malicious link received by email and clicked by the user). If you combine a stored XSS flaw and perform a request on the page load to execute some action,it will certainly work. The request comes from the application domain,so the application/browser will have no way ...


0

The Access-Control-Allow-Origin is a CORS header meant to check whether the request came from the same domain or not. The request is indeed sent from the same domain, but you might not have said so in the HTTP request header. I don't have much insight in your precise problem, but to me you should specify the Origin header: var xhr= new XMLHttpRequest(); ...


1

This appears to be the same as CSRF, except that the payload is executed by JavaScript. Because X-Frame-Options is set to prevent framing, the JavaScript can only be executed if the GET request is opened in a new window (or tab). <img> tags won't work because any HTML or script returned in the response won't be interpreted by the browser. If your ...



Top 50 recent answers are included