![](\"https:\/\/varutra-1a3b6.kxcdn.com\/wp-content\/uploads\/2021\/01\/CORS-1024x573.png\" "\\"CORS")
\nThe Cross-Origin Resource Sharing (CORS) is a mechanism to relax the Same Origin Policy (SOP) and to enable communication between websites, served on different domains, via browsers.<\/p>\n
\nThe Cross-Origin Resource Sharing (CORS) is a mechanism to relax the Same Origin Policy (SOP) and to enable communication between websites, served on different domains, via browsers.<\/p>\n
Inside this blog, the reader will find:<\/p>\n
![\"Cross-Origin](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Cross-Origin-Resource-Sharing-CORS.png\")
<\/p>\n
<\/p>\n
The same-origin policy is a web browser security method that aims to prevent websites from attacking each other. The same-origin policy limits scripts on one origin from accessing data from another origin.<\/p>\n
The term “origin” is defined using: Domain name, Application protocol, and TCP port.<\/p>\n
Two resources are considered to have the same origin if and only if all the preceding three values are the same.<\/p>\n
To better explain the concept, the following table shows the results of the control of the Same Origin Policy with respect to the URL http:\/\/www.example.com\/dir\/page.html<\/em><\/p>\n <\/p>\n <\/p>\n There are several techniques available for relaxing the SOP in a controlled manner. One of these techniques is Cross-Origin Resource Sharing. Through the configuration of additional HTTP headers, it tells the browser that a request generated by a web application running at origin \u201cA\u201d, has the permission to access the selected resource served on origin \u201cB\u201d.<\/p>\n The main header involved is the \u201cAccess-Control-Allow-Origin\u201d. This header allows the listed origin to make visitor\u2019s web browsers send cross-domain requests to the server and read the response. Something the Same Origin Policy would normally prevent. For example, Access-Control-Allow-Origin: https:\/\/example.info<\/em><\/p>\n By default, without the \u201cAccess-Control-Allow-Credentials\u201d header, a request will be issued without credentials (like cookies or HTTP Authentication data), meaning that it cannot be used to steal private user specific information. And if it is set to \u201ctrue\u201d by the server then it allows the browser to send authenticated requests to the target handler.<\/p>\n The following image shows a simple CORS request flow:<\/p>\n <\/p>\n <\/p>\n From an attacker\u2019s point of view, the best scenario is when the target CORS configuration sets the \u201cAccess-Control-Allow-Credentials\u201d header to \u201ctrue\u201d. In this case, the attacker can exploit the misconfiguration identified to steal the victim\u2019s private and sensitive data. And the basic technique is to create a JavaScript that sends a CORS request.<\/p>\n For example:<\/p>\n With this code, the attacker can steal the data through the \u201clog\u201d handler that receives the response from the vulnerable domain. When the victim authenticated on the target application (\u201cvulnerable.domain\u201d) visits the page containing the earlier code, the browser sends the following request to the \u201cvulnerable.domain\u201d:<\/p>\n And the application responds with the following:<\/p>\n Due to the two \u201cAccess-Control-Allow-*\u201d headers sent by the server; the victim\u2019s browser allows the JavaScript code included into the malicious page to access the private data.<\/p>\n <\/p>\n There is a possibility to bypass some controls implemented incorrectly using special characters inside the domain name.<\/p>\n This evasion technique exploits the fact that browsers do not always validate domain names before making requests. Therefore, if some special characters are used, the browser may submit requests without previously verifying if the domain name is valid.<\/p>\n Suppose the target application implements the following regular expression to validate the \u201cOrigin\u201d header:<\/p>\n The meaning of the above regular expression is likely to allow cross-domain access from all subdomains of \u201ctarget.local\u201d and from any ports on those subdomains.<\/p>\n \u201c[^\\.\\-a-zA-Z0-9]\u201d means any character except the “.” “-” “a-z” “A-Z” “0-9”<\/p>\n \u201c+\u201d means a quantifier, matches preceding chars one or more times.<\/p>\n \u201c.*\u201d means any character except for line terminators.<\/p>\n In this screenshot, no \u201cAccess-Control-Allow-Origin\u201d & \u201cAccess-Control-Allow-Credentials\u201d are set.<\/p>\n Since the regex matches against alphanumeric ASCII characters and \u201c.\u201d \u201c-\u201c, every other special character after \u201ctarget.local\u201d would be trusted.<\/p>\n Tamper the origin https:\/\/www.taget.local.example.com with https:\/\/www.taget.local{.example.com<\/p>\n The prerequisites to exploit this are: A domain with a wildcard DNS record pointing it to your server and NodeJS<\/p>\n Create a serve.js file:<\/p>\n Then in the same directory create the cors.html:<\/p>\n Now start the NodeJS server by running the command: node serve.js &<\/p>\n Due to the regular expression ^https?:\\\/\\\/(.*\\.)?target.local([^\\.\\-a-zA-Z0-9]+.*)? which is implemented on the target application, every special character, except \u201c.\u201d and \u201c-\u201c, after \u201cwww.target.local\u201d would be trusted, so the request generates a valid request and the attacker is able to steal data from the vulnerable target.<\/p>\n <\/p>\n For example, consider an application that reflects inside the response the content of the \u201cX-User\u201d custom header, without doing any input validation on it nor doing output encoding.<\/p>\n Request:<\/p>\n In response, note that the \u201cAccess-Control-Allow-Origin\u201d is set but the \u201cAccess-Control-Allow-Credentials: true\u201d and \u201cVary: Origin\u201d headers are not set as shown below:<\/p>\n An attacker can exploit this XSS by uploading the following JavaScript code on a controlled server and then making a victim to navigate on it:<\/p>\n If the \u201cVary: Origin\u201d header is not set inside the response, then the victim\u2019s browser may store the response in the cache and then displays it directly when the browser navigates to the associated URL which is shown below:<\/p>\n <\/p>\n Cross-Origin Resource Sharing (CORS) mitigation techniques:<\/u><\/strong><\/p>\n <\/p>\n \u00a0<\/strong><\/p>\n Author,<\/p>\n Avadhoot Dongare<\/strong><\/p>\n Attack & PenTest Team<\/p>\n Varutra Consulting Pvt. Ltd.<\/p>","protected":false},"excerpt":{"rendered":" The Cross-Origin Resource Sharing (CORS) is a mechanism to relax the Same Origin Policy (SOP) and to enable communication between websites, served on different domains,…<\/p>\n","protected":false},"author":4,"featured_media":7079,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"inline_featured_image":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[277,273],"tags":[336,337],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t![\"SOP](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/SOP-Scenario.png\")
<\/p>\nFig-1.1 SOP Scenario<\/pre>\n
Cross-Origin Resource Sharing (CORS)<\/u><\/strong><\/h3>\n
![\"Simple](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Simple-CORS-flow.png\")
<\/p>\nFig-1.2 Simple CORS flow<\/pre>\n
\n
![\"JavaScript](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/JavaScript-for-exploiting-with-credentials.png\")
<\/p>\nFig-2.1 JavaScript for exploiting with credentials<\/pre>\n
![\"Tampered](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Tampered-domain-or-attacker-domain.png\")
<\/p>\nFig-2.2 Tampered domain\/attacker domain<\/pre>\n
![\"Server](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Server-response.png\")
<\/p>\nFig-2.3 Server response<\/pre>\n
![\"Misconfigured](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Misconfigured-CORS-result.png\")
<\/p>\nFig-2.4 Misconfigured CORS result<\/pre>\n
\n
![\"Simple](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Simple-regular-expression-example.png\")
<\/p>\nFig-3.1 Simple regular expression example<\/pre>\n
![\"Captured](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Captured-request.png\")
<\/p>\nFig-3.2 Captured request\u00a0<\/strong><\/pre>\n
![\"Origin](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Origin-tampered.png\")
<\/p>\nFig-3.3 Origin tampered<\/pre>\n
![\"Serve.js](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Serve.js-contents.png\")
<\/p>\nFig-3.3 Serve.js contents<\/pre>\n
![\"Cors.html](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Cors.html-file.png\")
<\/p>\nFig-3.4 Cors.html file<\/pre>\n
\n
![\"Captured](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Captured-request-2.png\")
<\/p>\nFig-4.1 Captured request<\/pre>\n
![\"Server](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Server-response-2.png\")
<\/p>\nFig-4.2 Server response<\/pre>\n
![\"JavaScript](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/JavaScript-code-2.png\")
<\/p>\nFig-4.3 JavaScript code<\/pre>\n
![\"Misconfigured](\"https:\/\/www.varutra.com\/wp-content\/uploads\/2021\/01\/Misconfigured-CORS-result-2.png\")
<\/p>\nFig-4.4 Misconfigured CORS result<\/pre>\n
\n
References:<\/u><\/strong><\/h3>\n
\n