pillarjs / understanding-csrf Goto Github PK

services is SPA application and implement csrf token, the client is use httpclient to send post request, just want to know if have some good suggestion to send csrf token to httpclient

But for older browsers, this is pretty simple as long as the attack knows where to get a CSRF token.

Assuming the token is correctly implemented (per user session), how can an attacker obtain such CSRF token?

It seems to suggest older browsers are still vulnerable to CSRF attacks even when CSRF tokens are correctly used. I am not sure if that's the case.

Thx to recent update, my question in #2 are addressed.

I do have 1 more question: is it worth discussing ways of passing CSRF token to client?

• For traditional html form (server-side rendering), no problem, hidden input field with csrf token should do the trick.
• For client-sider rendering, framework must have a way to get the token from somewhere, 2 possible choices are use a cookie or put it in a meta tag, then they can be used to render hidden input field.

I guess both are valid options? though they both appear to have a drawback:

• Updating csrf token will be a problem for single page app, since exposing /csrf api is huge no-no. While reusing csrf token multiple times work, it kinda step on the BREACH attack? The best way I can think of is to Set-Cookie on AJAX response, so that client can re-render input field.

As a side-note: does it mean CSRF token really isn't designed for SPA, but for a Progressive Enhancement model? I mean if you are SPA, you should always use JSON body instead?

Not fully supported yet, but worth mentioning.

https://caniuse.com/#feat=same-site-cookie-attribute

https://tools.ietf.org/html/draft-west-first-party-cookies-07
https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#SameSite_cookies

Here https://github.com/pillarjs/understanding-csrf#disable-cors

It is unclear what doesn't use Javascript? Is it GET? One can make GET request with AJAX, right?

It would be nice if someone clears the confusion over this.

Thanks

The document says "An attacker would have to somehow get the CSRF token from your site, and they would have to use JavaScript to do so." But if the attacker uses other scripting language like Python rather than client-side JavaScript, she can get the CSRF token by programmatically simulating client GET/POST to get the CSRF token like this link. CORS does not prohibit such behaviour.

In this case, how to avoid attackers getting the CSRF tokens if the website has some POST through form.

I asked this in #3 but at the time I wasn't using JSON only API, so I didn't try it out.

Now that I am designing such an API, this question pops up again: it seems JSON only API is not immune from XSRF, you need at least request.type check and possibly more:

http://security.stackexchange.com/questions/10227/csrf-with-json-post

This is not an issue, I am creating this to just discuss my concern regarding securing the "secret" in cookie.

In the document understand CSRF, you have mentioned that make sure cookie sessions use httpOnly so the client can't read the secret via client-side JavaScript!

Concern: Do we actually need to secure the "secret" with httponly flag.

Now my point is, an attacker can read the response via client-side JavaScript by either CORS or XSS vulnerability. For now lets assume I as an attacker find an XSS on application. So as an attacker what I need is CSRF token and not "secret". And CSRF token will be present in either in response body or response header. So if I have an XSS vulnerability I can read the response and could get the CSRF token directly. So what is the point of securing the "Secret".

Let me know if I have any wrong understanding.

In a couple places this document emphasizes the following point: Make sure CSRF tokens can not be accessed with AJAX! Don't create a /csrf route just to grab a token.

I don't see the attack vector here. Such an endpoint would be no more or less secure than the usual practice of embedding the token in a hidden form field. In both cases the Same Origin policy will prevent a foreign script from reading the value.

That is: in both cases a foreign script can send a GET to that URL; in both cases the user's authentication cookie will be included, causing the server to return a valid CSRF token; and in both cases the browser's Same Origin policy will prevent the foreign script from reading the response to the GET, which keeps the token secure.

in the Chinese version “understanding-csrf”

original article：
As noted above, if you don't support CORS and your APIs are strictly JSON, there is absolutely no point in adding CSRF tokens to your AJAX calls.

Inaccurate：
正如上面提到的，如果你不支持CORS并且你的API是传输的严格的JSON， 绝没可能在你的AJAX 调用中加入CSRF token。

better：
正如上面提到的，如果你不支持CORS并且你的API是传输的严格的JSON， 在你的AJAX 调用中加入CSRF token 是毫无意义的。

One of your headings reads GET is always idempotent. Although that is certainly good practice in general, it doesn't have anything to do with CSRF. A GET request that deleted data would be idempotent, but still a major CSRF vulnerability.

I suggest GET should not have side effects, or something like that.

I think you're assuming that the information available is trivial and unimportant. Someone other than the authorized user is getting that data and private information could then be used to execute other types of attacks.

For example, I may not be able to directly transfer money from your account using a POST request, but I can GET all your banking information and then try and use that in other ways.

It is more robust than referrer checking and a nice addition to tokens.

http://seclab.stanford.edu/websec/csrf/csrf.pdf (proposed here)
https://wiki.mozilla.org/Security/Origin

Use only JSON APIs then
Disable CORS then
Make sure that none of your GET requests change any relevant data in your database. then
Avoid using POST and then :)
Don't use method override! and so on!

Are we allowed to make any changes in the database? :)))))

This page is referred in the first row of csurf readme, as this page referres csurf team. I'd rather expect something like this to understand something about CSRF!