1+ <!DOCTYPE qhelp PUBLIC
2+ "-//Semmle//qhelp//EN"
3+ "qhelp.dtd">
4+ <qhelp >
5+ <overview >
6+ <p >
7+ Web browsers, by default, disallow cross-origin resource sharing via direct HTTP requests.
8+ Still, to satisfy some needs that arose with the growth of the web, an expedient was created to make exceptions possible.
9+ CORS (Cross-origin resource sharing) is a mechanism that allows resources of a web endpoint (let's call it "Peer A")
10+ to be accessed from another web page belonging to a different domain ("Peer B").
11+ </p >
12+ <p >
13+ For that to happen, Peer A needs to make available its CORS configuration via special headers on the desired endpoint
14+ via the OPTIONS method.
15+ </p >
16+ <p >
17+ This configuration can also allow the inclusion of cookies on the cross-origin request,
18+ (i.e. when the <code >Access-Control-Allow-Credentials</code > header is set to true)
19+ 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.
20+ </p >
21+ <p >
22+ That can have dangerous effects if the origin of Peer B is not restricted correctly.
23+ An example of a dangerous scenario is when <code >Access-Control-Allow-Origin</code > header is set to a value obtained from the request made by Peer B
24+ (and not correctly validated), or is set to special values such as <code >*</code > or <code >null</code >.
25+ The above values can allow any Peer B to send requests to the misconfigured Peer A on behalf of the user.
26+ </p >
27+ <p >
28+ Example scenario:
29+ User is client of a bank that has its API misconfigured to accept CORS requests from any domain.
30+ When the user loads an evil page, the evil page sends a request to the bank's API to transfer all funds
31+ to evil party's account.
32+ Given that the user was already logged in to the bank website, and had its session cookies set,
33+ the evil party's request succeeds.
34+ </p >
35+ </overview >
36+ <recommendation >
37+ <p >
38+ When configuring CORS that allow credentials passing,
39+ it's best not to use user-provided values for the allowed origins response header,
40+ especially if the cookies grant session permissions on the user's account.
41+ </p >
42+ <p >
43+ It also can be very dangerous to set the allowed origins to <code >null</code > (which can be bypassed).
44+ </p >
45+ </recommendation >
46+ <example >
47+ <p >
48+ The first example shows a possible CORS misconfiguration case:
49+ </p >
50+ <sample src =" CorsMisconfigurationMiddlewareBad.py" />
51+ <p >
52+ The second example shows a better configuration:
53+ </p >
54+ <sample src =" CorsMisconfigurationMiddlewareGood.py" />
55+ </example >
56+ <references >
57+ <li >
58+ Reference 1: <a href =" https://portswigger.net/web-security/cors" >PortSwigger Web Security Academy on CORS</a >.
59+ </li >
60+ <li >
61+ Reference 2: <a href =" https://www.youtube.com/watch?v=wgkj4ZgxI4c" >AppSec EU 2017 Exploiting CORS Misconfigurations For Bitcoins And Bounties by James Kettle</a >.
62+ </li >
63+ </references >
64+ </qhelp >
0 commit comments