CSRF Guide #2814
CSRF Guide #2814
Conversation
There was a problem hiding this comment.
This is a pretty complete guide. I'd add an example on how to fix it using fastify echosystem code like https://github.com/fastify/fastify-csrf .
Also couple remarks on formatting.
(i can't verify grammar as i'm not english native0
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
Co-authored-by: Vincent LE GOFF <vince.legoff@gmail.com>
There was a problem hiding this comment.
I don't see what purpose this serves in the core repository. Fastify core does not provide any CSRF mitigation features. That is the domain of the fastify-csrf plugin. Further, this "guide" is a general dissertation on the concept of CSRF. Skimming through it, I do not see any way in which this guide is related to Fastify and Fastify core's relation to CSRF.
IMHO, this is no better than copying and pasting a Medium (or some other blog site) post into a project that is tangentially related to the topic.
I am 👎
|
I spent 8 months researching CSRF and coming up with this compressed information about all threat vectors that can be used to exploit or trigger CSRF attacks. I spend most of my day off today coming up with this, explaining the best I can to raise the awareness and the quality of the documentation you have regarding CSRF, so please don't consider my work a mere copy/paste from Medium. I did a scientific work and here I am sharing a part of it. P.S: I was asked to do this by someone on your security team and here you have it. if I wanted to write a Medium blog, I could have done it elsewhere... |
|
My point is that this document is not related to this project. It is written as a general weblog post and would be more appropriate as written on such a site. I did not assert that you copied it from anyone or anywhere else. My assertion is that any "documentation" we include in the Fastify project should relate to Fastify. |
There was a problem hiding this comment.
I agree with @jsumners and I would move this great article to fastify-csrf
Anyway, I think we should help the community and spread these security aspects.
So what do you think about creating a docs/Guides.md or docs/SecureYourServer.md that links those resources in the fastify org that a new software developer could learn from?
(ie: fastify-csrf, fastify-helmet etc..)
|
|
||
| There are many definitions for it in the literature, but the core idea remains the same; in a CSRF attack the victim’s browser is tricked by an attacker into sending a state-changing HTTP request with authentication cookies, which the victim did not intend. This exploits the fact that cookies are widely used on the internet and browsers [automatically attach them to requests][auto]. For instance, online shops, social networks, webmail applications, etc. use cookies to maintain state and track/re-identify users without needing to reauthenticate. The reason cookies are used is because HTTP is a stateless protocol. The server responds to a received request and then “forgets” about the connection. To prevent this statelessness of HTTP, the authentication information is stored somewhere in the server-side (e.g. session store, database, etc.) and the browser receives only an identifier (ID) from the server for that session, often via a cookie. The browser stores this cookie and when a user sends a request to the server, the browser will also automatically attach the cookie(s) for this web application. The server retrieves the Session ID from the cookie and looks up in its session storage or database to retrieve the user’s data, identified by the Session ID. | ||
| Many alternatives exist when it comes to forging a CSRF request. If a state-changing request can be executed through HTTP GET, then an attacker can exploit this in (mainly) two ways. One option would be for the attacker to send an email that contains a HTML tag with the CSRF payload (e.g. img src="http://bank.com/transfer?amount=x\&dest=y"). If the webmail application loads HTML images automatically, then the browser will send the HTTP GET request and the CSRF attack succeeds. The second option is for the attacker to trick the user into visiting his malicious website, which contains the above HTML image tag. Note that the attacker is not limited to only the <img> tag. The attack can be triggered by using different HTML tags, which usually provide a src attribute. However, in most cases, applications perform state-changing request through HTTP POST requests. In this case, the attacker has to create a hidden JS form in his malicious website with the exact form fields that the server is expecting. Then, the attacker can use JS's events (e.g. onload()) to automatically post the hidden form when the victim loads/visits the page. | ||
| CSRF can be considered a type of the confused deputy attack where the web browser (confused deputy) is tricked into sending a forged request (for a less privileged attacker) to a web application. A CSRF attack works because, by design, a web browser automatically attaches all cookies that it has for the target web application when a request is sent. A server that does not protect against CSRF would accept and execute the request as coming from the victim since the session cookie was part of the request. What is worse, the victim is not aware of the attack until when it is too late. The figure below shows the steps of a common CSRF attack. However, some conditions have to be fulfilled for the attack to work: |
There was a problem hiding this comment.
The figure below shows the steps
I was confused by this sentence because I would expect an image
| ### Impact of CSRF attacks | ||
| <a id="impact"></a> | ||
|
|
||
| The impact of the attack depends on the specific operation that is vulnerable to CSRF, but also on the privileges that the victim has. This can result in a money transfer, change of password, a purchase in a shopping website, account compromise, created admin user, etc. Sometimes CSRF can be even more dangerous than session hijacking. For instance, in a court case, the victim cannot argue that he did not perform a transaction because the IP of the request (although unintended) was that of the victim. To makes things even worse, the victim doesn't even know which malicious website he visited that triggered the CSRF attack. In the case of session hijacking, the malicious attacker logs in with stolen credentials (usually) from an IP address different from that of the victim’s. Therefore, in this case, the victim can argue that he was the victim of an attack. There have also been other examples of CSRF attacks that lead to [remote code execution with root privileges][remote] or [compromise of a root certificate][cert]. |
There was a problem hiding this comment.
I would change the he pronouns to be more inclusive
| The impact of the attack depends on the specific operation that is vulnerable to CSRF, but also on the privileges that the victim has. This can result in a money transfer, change of password, a purchase in a shopping website, account compromise, created admin user, etc. Sometimes CSRF can be even more dangerous than session hijacking. For instance, in a court case, the victim cannot argue that he did not perform a transaction because the IP of the request (although unintended) was that of the victim. To makes things even worse, the victim doesn't even know which malicious website he visited that triggered the CSRF attack. In the case of session hijacking, the malicious attacker logs in with stolen credentials (usually) from an IP address different from that of the victim’s. Therefore, in this case, the victim can argue that he was the victim of an attack. There have also been other examples of CSRF attacks that lead to [remote code execution with root privileges][remote] or [compromise of a root certificate][cert]. | |
| The impact of the attack depends on the specific operation that is vulnerable to CSRF, but also on the privileges that the victim has. This can result in a money transfer, change of password, a purchase in a shopping website, account compromise, created admin user, etc. Sometimes CSRF can be even more dangerous than session hijacking. For instance, in a court case, the victim cannot argue that he did not perform a transaction because the IP of the request (although unintended) was that of the victim. To makes things even worse, the victim doesn't even know which malicious website he/she visited that triggered the CSRF attack. In the case of session hijacking, the malicious attacker logs in with stolen credentials (usually) from an IP address different from that of the victim’s. Therefore, in this case, the victim can argue that he was the victim of an attack. There have also been other examples of CSRF attacks that lead to [remote code execution with root privileges][remote] or [compromise of a root certificate][cert]. |
|
|
||
| * [Cross-Site WebSocket Hijacking][ws]: (WS) connections are another possible attack vector. An attacker can write some code in his malicious website that initiates a WS handshake with the target server. Once the victim visits the page, the browser will send an UPGRADE request header together with the session cookie. In a normal scenario, the server responds with CORS response headers that would prevent the cross-origin connection. However, the interesting fact is that WS does not respect SOP or CORS policy and the connection will actually be established. As a result, the attacker can now leak the CSRF token and forge successful CSRF attacks. | ||
|
|
||
| * Incorrect SOP relaxation (e.g. faulty CORS)**: is also a possible attack vector that can lead to CSRF token leakage. An over-permissive CORS that sets the response headers Access-Control-Allow-Origin: true and Access-Control-Allow-Credentials:true would leak the CSRF token of the victim. The attacker can simply perform a GET request to retrieve the CSRF-protected HTML form, read the response and steal the CSRF token. Then, he can continue performing a CSRF attack by providing the valid CSRF token. |
|
|
||
| * Incorrect SOP relaxation (e.g. faulty CORS)**: is also a possible attack vector that can lead to CSRF token leakage. An over-permissive CORS that sets the response headers Access-Control-Allow-Origin: true and Access-Control-Allow-Credentials:true would leak the CSRF token of the victim. The attacker can simply perform a GET request to retrieve the CSRF-protected HTML form, read the response and steal the CSRF token. Then, he can continue performing a CSRF attack by providing the valid CSRF token. | ||
|
|
||
| Note: SameSite cookies appear to be the next attempt to prevent CSRF attacks. Although SameSite raises the bar for attackers, it is not perfect as well. For example, SameSite: Lax does not completely prevent CSRF. Three possible attacks can be exploited: 1) attacker can use top-level navigation (<a>) to trigger GET-based CSRF. 2) “Client-side” CSRF can circumvent this mechanism and even send POST-based CSRF requests with cookies attached. 3) <portal>, a new HTML tag that was introduced by Google in the end of 2019 for performant website framing. Until now, it is still a draft and only available on Google Canary. However, developers should be aware of the security risks. If the target web application is embedded into attacker’s site using <portal>, then the browser [will send the SameSite=Lax cookie even if it is a cross-origin request][portal]. Recent attacks show that [SameSite can also be circumvented with other means] [fb]. |
There was a problem hiding this comment.
This link [SameSite can also be circumvented with other means] doesn't work
| I hope that developers become aware of these attack vectors and read the documentation of the framework they use carefully. There is currently no framework that prevents all these attack vectors and if security is your priority, make sure to check that you are safe from the above-mentioned attack vectors. | ||
|
|
||
|
|
||
| -Author: Xhelal Likaj (xhelallikaj20@gmail.com) |
There was a problem hiding this comment.
It renders as a block code due the spaces, maybe a <div> would fix it
|
@Eomm OWASP provides a lot of useful guides/cheat sheets for security, so it seems a bit redundant to have that content duplicated into Fastify repos? The guides on OWASP could do with an update though as, when node web apps are referenced, it only provides links and examples using Express middleware and not Fastify plugins. I'm happy to go through their guidance and make the required pull requests if needed. |
I didn't want to duplicate the content but I was thinking about to a kind of "awesome list" of security concern tailed to the fastify ecosystem. In my mind, I was thinking this: |
|
I find the idea great tbh. A part of my (private) vulnerability report included some issues that could be easily fixed with Helmet. And OWASP is already cited in my CSRF guide (links lead to multiple of its articles, to the the relevant content). Let me know what you all agree to and I can move things around. |
We have a "Guides" section being created in #2610. But they should still be related to Fastify itself. They are meant to be informal tone documents instead of reference tone documents. |
|
I think this will be great to live in the docs of the website. It's hardly discoverable inside fastify-csrf. |
|
El lun., 25 de enero de 2021 2:10 p. m., Matteo Collina <
notifications@github.com> escribió:
… I think this will be great to live in the docs of the website. It's hardly
discoverable inside fastify-csrf.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2814 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJXTQT7LLL356RFI7C3OQGTS3XFZZANCNFSM4WPV6QAQ>
.
|
|
This is a good write up. It should live in the main docs under a |
@jsumners is right, whilst good it is a blog post. It's even referenced in another pull request to another framework as such: vertx-web-site/vertx-web-site.github.io#91 |
|
It is referenced in another framework because they asked me to write it as well. I am the author of it as well. The security topics are not scoped to Fastify alone but to web itself. I cannot write 2 different articles explaining the same attack vectors. Instead. this can be enriched with fastify-based examples (as rightfully suggested by some of you) and to me it would look like a very good documentation both theoretically and practically. However, the decision rest on you. I wrote the guide because I was asked to and did my best to cover as many vectors as possible, as briefly as possible. I am not aware of any blog covering them all together, especially seen in the CSRF context. |
|
Closing due to inactivity and a lack of response to issues raised. |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Checklist
npm run testandnpm run benchmarkand the Code of conduct