New answers tagged

-1

It's effectively your rails endpoint that needs to protect itself. It needs to differentiate between your static pages and someone else's malicious page on the internet. I agree that having the rails endpoint check the referrer is a fragile way to authorize access. One possibility is to have the rails endpoint have a route that is not CSRF protected, and ...


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 ...


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

Yes and no. Yes because it can modifies information without the user consent but no because it cannot gather information. CSRF is a blind attack. CSRF stands for Cross Site Request Forgery. The idea is that when you visit a malicious site, this site will initiate a request to a target site. For example : I visit malicious.com and when I hit their page they ...


5

A CSRF attack is a blind attack where the attacker can control the request sent to the server, but due to the same origin policy cannot get the contents of the HTTP response. To get the response one would need something like Cross-Site-Scripting or DNS-Rebinding attacks. That's at least the case with the default behavior, but if the target server employs a ...


3

Potentially, yes. But only if you have far worse security concerns. If you expose any endpoints that initiate data-transfer to a new location (such as changing the email address on an account) a CSRF attack allows the attacker to send a request to this, which could enable access to their data. However generally no, CSRF attacks are blind, and often use ...


0

I glanced through the code for the function and it seems to only be using the User ID for verification, that means that the attacker and victim will have the same nonce? Is this really correct? Looking at the code it can be observed that the session identifier is used as part of the nonce generation: $token = wp_get_session_token(); $i = ...


3

The blog post from Paul Moore holds back quite a lot of information, probably on purpose, seeing that asda hadn't fixed the issue when he published the post. Here is an article that is a bit more explicit about the vulnerabilities of Asda. CSRF Vulnerability First of, they did not seem to have any CSRF protection: There is no XSRF protection ...


0

Assuming stored XSS were possible, the stored XSS could use the echo endpoint to present a phishing version of the site (since further XSS resource loading through the echo would be permitted and trusted due to the same origin it was coming from).



Top 50 recent answers are included