asked on
Further queries: CSRF inapplicable for system to system calls
Refer to above thread which I've told the applications vendor
that an independent pentester will still flag out CSRF.
From me to vendor: "the site (hosting the URL) will have no way to distinguish
between the forged request sent by a browser/person or a system."
From the apps vendor to me:
"You are right that the server cannot distinguish requests sent by a browser or system, but it is more like a general statement about the statelessness of web servers. The whole idea of CSRF depends more on the browser auth mechanism that automatically attaches legitimate credentials to the user request that the server recognises. Is the exploit possible if the application server does not accept auth mechanisms such as Cookie/Basic/Digest Authentication. From the application designer point of view, we simply want to caution against overreliance on automated scanning tools.
Some references for discussion:
https://security.stackexchange.com/questions/170388/do-i-need-csrf-token-if-im-using-bearer-jwt
For the API endpoint that is meant for system-to-system call, the only situation where an attacker can forge a legitimate request and a signature acceptable to the server is when the shared secret used to sign the message is compromised. A browser is not involved. The endpoint also does not accept any other form of the authentication mechanism and we deliberately designed the mechanism as such to balance system integrity and availability. We can enforce CSRF token to help with compliance but do bear in mind that it really translates to integration complexity in future. "
I've yet to ask the vendor to elaborate what kind of integration complexity but
meanwhile, are the vendor's arguments valid?
1. "... exploit is not possible if the application server does not accept auth
mechanisms such as Cookie/Basic/Digest ?"
2. "the only situation where an attacker can forge a legitimate request & a signature acceptable
to the server is when the shared secret used to sign the message is compromised. "
3. I guess the vendor's argument "not to over rely on SAST scans" & "The endpoint also does
not accept any other form of the authentication mechanism" are not valid if an
independent penetration test show the URLs are still CSRF-vulnerable, right?
ASKER
vendor is using the free Snydk) to scan as well as an external
CREST pentester to verify: if Coverity & pentest reveal the
CSRF is there, I told the vendor it's not a case of "over -
reliance on SAST". Also, I ask the vendor to illustrate the
cases of 'complexities in future integration' : rather I ask
vendor to implement & if this truly give rise to complexities
in future, we'll remove the 'token' implementation.
Concern is once the project is over & vendor has 'washed
hands', when future pentests reveal this vulnerability, we'll
have to engage the services & foot the bill again to remediate.