New answers tagged

0

It can't. Wikipedia is just wrong here (and has been edited, as of this answer). In fact, the cookie itself is utterly unnecessary in this scenario. On the server, don't look for any particular value in the X-Csrf-Token header, just make sure it is present. Then, don't return Access-Control-Allow-Headers: X-Csrf-Token (or ACAH: *) - at least, not for any ...


-1

The problem you're solving seems to be "has this browser been on this website before", which is what the cookie would indicate. Loading the login page (in an iframe, etc) would create that cookie on the victim's browser anyway. In order to prevent CSRF, you'd need a hidden value that is to be submitted as part of a payload, not just as a cookie ...


-1

No, if you don't do anything else, there can be different problems. Here are just some examples. If you use don't filter user input and if you use SQL in the login logic, an SQL injection may be possible, which, depending on database, permissions, SQL etc. can have different consequences, e.g. your application can accept arbitrary passwords, or such ...


0

Cookie is the cookie and there is no difference what value is stored in it. It is only a string. You have to check all cookie attributes like: domain, path, flags. From my experience first I would look for is secure flag. Often when developers are testing some feature on localhost they forget to use HTTPS with localhost (I do not recommend to set secure=...


0

So how does it help against XSS and CSRF attacks? They generally don't. Not every product with SDP on the label will do that. This looks more like a capability for a Next-Generation Firewall that can decrypt traffic, inspect content, and detect XSS/CSRF problems (assumed to be threats or attacks). Furthermore, a Web Application Firewall is also a component ...


Top 50 recent answers are included