From 8525c58e1ae34f0a813ac17cdfae34d1fe9f0619 Mon Sep 17 00:00:00 2001 From: Slavomir Date: Mon, 24 May 2021 15:19:50 +0200 Subject: [PATCH] Improve qhelp doc --- .../CWE-942/CorsMisconfiguration.qhelp | 32 ++++++++++++++++--- 1 file changed, 27 insertions(+), 5 deletions(-) diff --git a/ql/src/experimental/CWE-942/CorsMisconfiguration.qhelp b/ql/src/experimental/CWE-942/CorsMisconfiguration.qhelp index c6493645c63..cbcf206c01a 100644 --- a/ql/src/experimental/CWE-942/CorsMisconfiguration.qhelp +++ b/ql/src/experimental/CWE-942/CorsMisconfiguration.qhelp @@ -4,11 +4,33 @@

- When configuring the allowed origins for CORS requests that allow passing cookies - (i.e. the Access-Control-Allow-Credentials is set to true), - if the Access-Control-Allow-Origin header is set to a user-provided value (and not correctly validated), - or is set to special values such as * or null, then the users of that application might be - vulnerable to attacks where the attacker impersonates the user and sends request on their behalf. + Web browsers, by default, disallow cross-origin resource sharing via direct HTTP requests (i.e. using a JavaScript HTTP client). + Still, to satisfy some needs that arose with the growth of the web, an expedient was created to make exceptions possible. + CORS (Cross-origin resource sharing) is a mechanism that allows resources of a web endpoint (let's call it "Peer A") + to be accessed from another web page belonging to a different domain ("Peer B"). +

+

+ For that to happen, Peer A needs to make available its CORS configuration via special headers on the desired endpoint + via the OPTIONS method. +

+

+ This configuration can also allow the inclusion of cookies on the cross-origin request, + (i.e. when the Access-Control-Allow-Credentials header is set to true) + meaning that Peer B can send a request to Peer A that will include the cookies as if the request was executed by the user. +

+

+ That can have dangerous effects if Peer B origin is not restricted correctly. + An example of a dangerous scenario is when Access-Control-Allow-Origin header is set to a value gotten from the Peer B's request + (and not correctly validated), or is set to special values such as * or null. + The above values can allow any Peer B to send requests to the misconfigured Peer A on behalf of the user. +

+

+ Example scenario: + User is client of a bank that has its API misconfigured to accept CORS requests from any domain. + When the user loads an evil page, the evil page sends a request to the bank's API to transfer all funds + to evil party's account. + Given that the user was already logged in to the bank website, and had its session cookies set, + the evil party's request succeeds.