Hot answers tagged

24

Your understanding is correct. Background The simplest way to think of a CSRF attack is that your browser has two tabs open - Tab A: www.mybank.com and Tab B: www.attacker.com. (As @Alex points out in comments, multiple tabs are not necessary; the important part is that your browser has auth cookies for mybank.com in memory. CSRF can equally happen if ...


7

Previous answers are rock solid. I'll jump in here to provide a more context and little caveat. There are lots of ways to using JWT; session management is one of them. Although it presents a few drawbacks when dealing with timeouts and advanced requirements like re-authentication. Also, I've seen JWT placed in Cookies. As other's have stated, CSRF ...


7

Expanding on the answers of @Sjoerd and @lindon. Origin vs Referer vs CSRF token Most likely, the reason OWASP recommends also using a CSRF token, is that at the time when this recommendation was made - a significant portion of browsers did not yet support the Origin header. This is no longer the case, but people are chimpanzees. In order to preserve ...


6

The attack vector here is disclosure of the token. The defense is not so much concerned with specifically how that token is disclosed, but addresses any method in which an attacker might obtain that value. If an attacker can obtain the token, that opens the possibility they can craft a CSRF attack. Again, the specific method of attack itself isn't the ...


4

Whether or not CSRF protection is needed is based on 2 factors: - Is the request doing a state changing action (not the same as REST API Statelessness) - State changing actions are any action that will change the state of the application.. for example delete something, add something, update something. These are actions using which the application will ...


4

Output encoding is context-specific. If you're only putting the output of this function into HTML text elements - not into attributes, not into strings (or anywhere else) in a script, not into CSS, etc. - you might be OK. For now. If you're aiming for any other context, you're definitely not OK. Here are just a few (this isn't a comprehensive list, don't try ...


4

Firefox 67 and 68 added multiple possible settings for privacy and Third-Party-Cookie-Blocking. As far as I understand, your demo seems to include usage of Third-Party-Cookies. You can find the information at the information page about content-blocking from Mozilla. The main reason for the change were protecting against being tracked by Third-Party-...


4

However, how is this safe? A malicious website can do the exact same thing, hit my log in, receive the token, add to token to header, and then do anything. The malicious website could grab a csrf token, but as your server will have a different csrf token for each user session, it will be of no use to the malicious website. To better understand csrf attacks,...


3

When exploiting a CSRF vulnerability, you are changing the state of the server (i.e. writing). You are not stealing data (i.e. reading). The browsers same origin policy (SOP) is preventing you from reading the HTTP response. It sounds like you found an endpoint with no CSRF protection, but all it does is returning sensitive data without changing the state ...


3

It depends what browsers you want to support and how your site is currently set up. If you are strictly supporting only browsers that support the feature then it should be sufficient if you're willing to either: Not send cookies with top-level navigation (this is quite restrictive as you can't link to logged-in pages externally) Ensure no operations use ...


3

Refresh tokens This is quite similar to the refresh token pattern. In it, you have two JWTs - one short lived for ordinary requests, and one long lived for renewing the short lived one. The short lived can not be revoked, but the long lived can. This is a pattern that is commonly used, giving a good trade off between revocability and performance. Your ...


3

If you have XSS, you can do literally anything that a script on the page could do. Read all the user's data on that site. Steal secrets (for that site) from their local storage. Prompt them to download malicious files from the trusted site. Tamper with the path to any file they do download, before they get it. Impersonate them in posts (on that site). Delete ...


3

Same-origin policy prevents a website from reading another website, which also prevents it from extracting the token to perform a CSRF attack.


2

With a normal CSRF attack, only Simple Requests are vulnerable. Those docs detail the requirements for a "simple request", but a request that uses content-type of "text/x-gwt-rpc" is not a simple request. Although traditional CSRF attacks can only exploit simple requests, you can use Flash to exploit "complicated requests". The attack is more complicated, ...


2

I am in the same situation as you, and here is how I understand the process: The server sends the JWT token via Set-Cookie ... ; Secure ; HttpOnly. This will prevent Javascript on the client to read the JWT token, and hence it will prevent XSS attacks to steal the JWT token. The server also sends a XSRF token that the Javascript on the client side can ...


2

One thing I would add to the other answers is that CSRF protection is necessary only in the domain and path of the cookie in question. Or put another way: Authorization != Authentication Cookies == Authentication Token == Authorization This is relevant to the implementation of persistent logins (your 3rd point). If you affix your cookies to login....


2

Here is the route I took eventually, thanks to the video at https://www.youtube.com/watch?v=GWLMmkv3z38: Identify the anti-CSRF token (e.g. hidden csrf_token field within the form) Go to Project options > Sessions > Add to record a new macro. In Macro Recorder, select the HTTP request from the proxy history and click "OK". Select the Macro Item and hit ...


2

the completely violates the use of having a csrf token.Let me explain why. when ever a victim submits any request his browser automatically submits the cookies associated with that domain.so csrf works because the broken submits the session credentials(if victim is logged in).so if you put anti csrf token then it will be submitted along with it.instead you ...


2

CSRF will have to be set in the request header. The anti-CSRF-token will be submitted in the request message body. If there is a XSS-vulnerability and an attacker manages to exploit it, the last thing he will probably care about is the anti-CSRF-token. XSS is a much more powerful attack, and an attacker can manipulate almost anything with XSS. Also, the ...


2

In general, a browser sends all the cookies it has for site A whenever it makes a request to site A. It doesn't usually matter where the request originated. There are two cases where it does, though: JavaScript-initiated requests (XMLHttpRequest or fetch) will send cookies by default for same-origin requests, but not by default for cross-origin requests. ...


2

if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks? No! However, you absolutely shouldn't be using GET like request methods for state changing actions. Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern? Yes! Since it omits sending cookies (flagged SameSite) to requests originating from ...


2

The term "CSRF" is very broad and, in my opinion, your definition of CSRF is not entirely accurate. A CSRF vulnerability's abilities depend on what endpoint is actually vulnerable to CSRF. Being able to send a request on behalf of a user that changes their profile picture, for example, wouldn't fall under your definition of CSRF above. If you have discovered ...


2

Our conversation started in the comment section, but I realized some inaccuracies in what I wrote. The sharing of cookies across domains is stricter than I thought at first. This should be a more comprehensive overview, and closer to what you might be looking for. I will make a few assumptions: You have two domains: foo.com (ui) and bar.com (api) You want ...


2

Is there any way such that the attacker can view the response generated when the victim clicks on the button? No, not in a pure CSRF attack. The direct effect of a CSRF attack is not information disclosure. It is tricking the server to perform some action. Examples of CSRF attacks would be: Delete a post by directing a CSRF attack at example.com/posts/...


2

One of the critical requirements of a properly-implemented CSRF protection is that the anti-CSRF token needs to be unique for each user. The attacker's web server can get a token from the vulnerable site, but it won't (well, shouldn't) be the victim's token. If the site issues the same anti-CSRF token to all users, then the site is vulnerable to CSRF; just ...


2

Visiting a URL can cause a side effect. For instance, if I'm logged into Amazon, visiting a URL may cause an item to be purchased and shipped to me (one-click buy). That's a side effect. Or, it might log me out, or log me in, or update some settings. Those are side effects, too. In general, a operation has a side effect if it changes some (persistent) ...


2

You don't need an AJAX request, the standard approach to exploit this issue would be: <form id="myform" method="post" action="http://mysite.vulnerablesite.com/mysite/deleteUser" > <input type="hidden" name="userId" value="5"> </form> <script>document.createElement('form').submit.call(document.getElementById('myform'));</script&...


2

Assuming the target website have a permissive cross origin resource sharing configuration or you found XSS on the target website (I guess it's how you got that token from), you could just make an AJAX request specifying your custom XSRF header. $.ajax({ type: "POST", beforeSend: function(request) { request.setRequestHeader("XSRF-Token", yourToken); ...


2

You're on the correct train of thought, in that as long as there is an element to the request that is not guessable/shared between users CSRF isn't possible. The issue at the core of CSRF is that cookies are sent automatically by the browser, which is a problem when the cookies are the only part of the victim's request that an attacker doesn't know. ...


2

Yes. Imagine spearphishing a high-profile user whose username you already have. All you need is to send them to your crafted CSRF page and you have taken over their account. Or equivalently, a mass phishing campaign if the web application accepts your email address as an alternative username. CSRF on security-critical flows is incredibly dangerous. You ...


Only top voted, non community-wiki answers of a minimum length are eligible