All your services / applications and the whole solution may be working from the functional perspective, however there are still many things to do before you can go to production. One such activity is making sure that there are no security vulnerabilities.
Suddenly, a colleague of yours is asking: Why do we have this
httpSecurity.csrf((csrf) -> csrf.disable());
here??? We need to be protected against everything, including CSRF, right?
(This is from Spring but you may see something similar with other frameworks.)
You start scratching your head trying to remember what CSRF actually is... Or you know immediately because you've read this post :)
Imagine two people, Alice and Eve, working with their computers, sitting next to each other. Eve is evil, trying to attack Alice, but to not show it, she will never look at Alice's keyboard or display. Instead, while Alice goes for a tea, Eve will plug her own keyboard in Alice's USB port.
When Alice comes back and unlocks her machine, Eve can type something evil that will be executed in Alice's name, like "send money to this account" or "drop the database". Of course, Eve has to guess the moment to type when Alice puts focus on the right window...
The attack works because Alice's machine can't tell that it is not Alice, but somebody else typing.
CSRF means Cross-Site Request Forgery; instead of keyboards connected to the same computer we have HTTP requests sent from the same browser.
One of the requests is a legitimate login to a web application, e.g. internet banking, resulting in a session cookie being stored by the browser. Another one is a request from a malicious website that looks exactly the same as a legitimate request to send money.
The session cookie is added to the request automatically by the browser, so the request is authenticated and will be executed by the server!
How to prevent CSRF? We have to make sure that the sensitive requests cannot be guessed (excluding the automated cookie appended by the browser). So we need something dynamic, random, added to the request explicitly.
The CSRF protection in Spring (or another framework) checks an additional non-cookie parameter in the HTTP request.
Luckily, well-designed REST APIs usually don't rely on session cookies, they are stateless. That includes authentication where the preferred method is Open ID Connect (OAuth). An authentication token (in the JWT format) is sent in the "Authorization" header with every request. You can learn more about securing REST APIs in our book (see love2integrate.com).
So, you can reassure your colleague that with stateless APIs that don't use cookie authentication it is OK to have the CSRF protection turned off.
See also:
BTW, why did we say that Eve was constrained not to look at Alice's screen? Well, CSRF is a write-only attack. Reading responses is blocked thanks to the "same-origin policy", a protection that browsers implemented a long time ago: Same-origin policy.
However, with complex JavaScript frontend frameworks and content delivery networks it may be necessary to relax the same-origin policy. For that we need to know another web security setting, CORS (Cross-Origin Resource Sharing). If you are interested, I can write about that another time.
Top comments (0)