Improve qhelp doc

This commit is contained in:
Slavomir
2021-05-24 15:19:50 +02:00
parent 74f8f1dcdb
commit 8525c58e1a

View File

@@ -4,11 +4,33 @@
<qhelp>
<overview>
<p>
When configuring the allowed origins for CORS requests that allow passing cookies
(i.e. the <code>Access-Control-Allow-Credentials</code> is set to true),
if the <code>Access-Control-Allow-Origin</code> header is set to a user-provided value (and not correctly validated),
or is set to special values such as <code>*</code> or <code>null</code>, 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").
</p>
<p>
For that to happen, Peer A needs to make available its CORS configuration via special headers on the desired endpoint
via the OPTIONS method.
</p>
<p>
This configuration can also allow the inclusion of cookies on the cross-origin request,
(i.e. when the <code>Access-Control-Allow-Credentials</code> 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.
</p>
<p>
That can have dangerous effects if Peer B origin is not restricted correctly.
An example of a dangerous scenario is when <code>Access-Control-Allow-Origin</code> 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 <code>*</code> or <code>null</code>.
The above values can allow any Peer B to send requests to the misconfigured Peer A on behalf of the user.
</p>
<p>
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.
</p>
</overview>
<recommendation>