9

We recently ran a Veracode SAST scan on our application and discovered that it has a CSRF. However, I wanted to check whether this is really true or it's just a false positive.

  1. Our application is a pure backend server. Serving JSON APIs to the users.
  2. Users will be calling these APIs from their backend in 99.99% of the cases. That means they will not be calling these APIs directly. Some HTTP Client/Application/SDK will be used.
  3. We cannot control the client side of the application.

These are the three constraints in which our application is going to be used. Now, my question is, does this make the application safe from CSRF and can we go ahead and mark this flaw as false positive?

Saif
  • 193
  • 1
  • 4
  • 2
    1. What do you mean by *pure* backend server? What server that serves JSON API to users is *not pure* for you? Do you mean your application provides services only, without any frontend? – mentallurg Feb 15 '22 at 01:37
  • 2. How will your API be used in the remaining 0,01%? Will it be used from web applications, i.e. from web browsers? – mentallurg Feb 15 '22 at 01:41
  • 1
    @mentallurg Yes, only services. No frontend. The users may use other types of http clients for testing, during onboarding. But they will most probably use tools like postman and stuff and not web browsers. – Saif Feb 15 '22 at 02:23

4 Answers4

18

Our application is a pure backend server. Serving JSON APIs to the users.
Users will be calling these APIs from their backend in 99.99% of the cases.
...

It does not matter what the API is serving or how the user is supposed to call the API. Attackers don't care about how something is supposed to be used but typically rely on not intended functionality.

If authentication credentials are automatically sent and no cross-origin detection or protection is done, then an authenticated client can be tricked into making in authenticated requests controlled by the attacker.

Authentication credentials are automatically sent with cross-origin requests when basic authentication is used or cookies - although many modern browsers nowadays limit the problem by making cookies same-site by default. Other automatically sent authentication methods are client certificates or Kerberos resp. NTLM tickets. If the attacker can induce the client to make such a request then the attacker does not need to actually know the authentication information - the client will add these by its own to the request.

Sometimes "authentication" does not rely on specific credentials but simply allows anything which comes from specific IP addresses or network. While a cross-origin request is triggered from "outside" it is using the clients browser to actually do the requests which thus comes from "inside" and is treated as authenticated.

If the API instead relies on something like an authentication token which explicitly needs to be added to each request, then the attacker would need to know the authentication credentials and cannot blindly trigger an authenticated request. In this case CSRF would not be doable.

Similar if the API requires requests which are not simple for example by requiring special HTTP headers, then CSRF can not be done unless the site employs a weak (non-default) CORS setup.

can we go ahead and mark this flaw as false positive?

Too few is known about your actual API to decide on this.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Regarding the comment about simple requests, is that not only protected by convention? I know modern browsers would send a 200 OPTIONS request first to ensure that the API call passed any CORS configurations before sending the actual API call, but would older browsers also do that? In short, my understanding is that CORS allows your users to benefit from the protections offered by modern clients but does not actually provide any protection for your API if your users are using browsers that don't implement CORS. – David Jacobsen Feb 16 '22 at 18:46
  • 1
    @DavidJacobsen: Older browsers with no support for CORS would not do Javascript initiated cross-origin requests in the first place since this was the original security design when Javascript was introduced many many years ago. CORS loosened this restriction but required pre-flight for non-simple requests. – Steffen Ullrich Feb 16 '22 at 18:50
8

If your API server uses cookies (or HTTP Basic/Digest/Kerberos) for authentication, then you need anti-CSRF measures. Even if you don't expect a web browser to be used with it, somebody could do so (as you say, you don't control the client). Additionally, some things that aren't browsers are browser-like in their behavior (e.g. webviews in mobile or desktop apps), and those are also at risk.

If you don't actually use any credentials that are sent automatically by browsers (cookies, HTTP auth, sometimes TLS client certs), then you aren't actually vulnerable to CSRF and can dismiss the finding as a false positive.

CBHacking
  • 40,303
  • 3
  • 74
  • 98
  • Good point about client certificates and Kerberos also being automatically included credentials. I've included it in my answer. – Steffen Ullrich Feb 15 '22 at 07:14
2

CORS only matter when embedding API content on another sites' frontend, or some WebView; while CSRF generally just makes sure, that the form which is being posted had been recently loaded from the same server. While I find it difficult to see the actual attack vector, when the communication is server to server. The XSS cheatsheet should confirm this claim.

1

Same issue I also got while doing SAST scan, even in my case have disabled csrf through spring security. But we know that our rest api needs an authentication token each time we access it. In my opinion csrf attack would not be possible here.

Sudhir
  • 111
  • 2
  • 2
    Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 16 '22 at 18:22
  • As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 17 '22 at 02:32