New answers tagged

1

In addition to your own answer, CSRF defences are still recommended and are useful: "SameSite" cookies offer a robust defense against CSRF attack when deployed in strict mode, and when supported by the client. It is, however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and ...


1

These scenarios are addressed in Version 6 of the spec. It defines Strict (default) and Lax modes, where strict would not send cookies even for top level navigations, and Lax would send cookies for top level navigations, but wouldn't for "unsafe HTTP methods" including POST. The answers for the two scenarios are therefore: JS navigations and link clicks ...


1

You can use some authentication scheme, where clicking that button will make server generate the token that is signed or maced and make the second server trust that. Then you can pass that as a parameter in the URL, but this scheme will allow anyone who gets the token to use that (I am not sure if you are doing that for security or as a some UI feature). ...


0

From reading the section 7.1 "Limitations" I would assume that the author of the RFC is aware of the limitation you describe. First-Party-Only cookies are not seen as the all-encompassing protection against CSRF. First-Party-Only cookies are only indented to protect against CSRF which are invisible to the end user. This means that it does not intend to ...


2

No, the Same Origin Policy also protects against: Cross domain manipulation in the DOM (e.g. a page manipulating another page from another origin loaded in an IFrame). The response from AJAX requests being read when the origins don't match. Images loaded from other origins from being read into an HTML5 canvas. So my question is: would we really need ...


5

Yes you need a MAC in order to ensure the user hasn't manipulated the value to something else which is a valid user id once decrypted. Also, rather than MAC <userid> you should add some context around it, and then mac that. e.g. userid=<userid> This will prevent a substitution attack elsewhere on your site with data that has been MAC'd. For ...


1

HTTPS only prevents 3rd parties from doing man-in-the-middle attacks and manipulating the connection (including the cookie). HTTPS does not do anything to protect you from a malicious user. The user could edit their own cookie. You need to use authenticated encryption or sign the cookie's contents yourself if you don't want the user to try to edit the id in ...



Top 50 recent answers are included