XSS Cookie Based ( Self XSS or Indirect XSS)

Recently in one of the many reports that I usually send to hackerone weekly, I found an XSS in a parameter of the Cookie, after reviewing my report, the company to which I reported said XSS decided that XSS was out of scope, because it was a Self-XSS.

In my point of view it is not a Self-XSS, since a Self XSS is based on you should to manipulate the source code of a user's browser and add that malicious code, I define it seems to match the definition of Wikipedia:

"Self-XSS is a social engineering attack used to gain control of victims' web accounts. In a self-XSS attack, the victim of the attack accidentally runs malicious code in his / her own web browser, thus exposing it to the attacker."

In order to understand the problem, we will perform the vulnerability.

On the one hand, an unauthenticated user is able to inject JavaScript code into one of the Cookie parameters, which could allow a persistent XSS in the browser cache of the victim. We can see this in the next example:

GET / HTTP/1.1 Host: www.vulnerable.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64;
Trident/5.0) Connection: close Cookie: vuln=</script></script>alert(1)</script>

The affected parameter of the cookie in this case is Vuln, inserting the sequence <script> <script> alert (1) </ script> returns the following response:

HTTP/1.1 200 OK Server: www.vulnerable.com Date: Thu, 31 Aug 2017 16:21:36 GMT Content-Type: text/html; charset=UTF-8 Connection: close Cache-control: no-cache, no-store Vary: Accept-Encoding Content-Length: 68020 ..] </script> <script>window.vulnerable_page_name = "boom"; window._tracking_segments_cookie = "bid|</script></script>alert(1)
</script></script>" ..]

Once the XSS is executed, it is saved in the browser cache, since it is a cookie and has been set to <script> <script> alert (1) </ script> value, erase your browser's cache will remain there.

I suggest that it is possible to exploit this vulnerability through cURL, using the following command:

curl -i -s -k -X $'GET' \ -H $'User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64;
x64; Trident/5.0)'\
-H $'Referer: www.vulnerable.com' \ -b $'vuln=</script></script>alert(1)</script> ' \ $'https://www.vulnerable.com/'

They respond as follows:

"Hi 

The exploit you describe is a "self-XSS". As cookies are set server-side and sent to/from the client via headers (as you noted via the use of the '-b' parameter on CURl), it would require a MITM or endpoint compromise to intercept the cookie headers.

Kind regards,
"

They in that part are right, without a proxy or without compromising an a priori endpoint and without further information it is not possible to set the cookie through a GET request ...
Once I have this answer I decide to investigate on how to get a full XSS through this vulnerability, so I am going to analyze the entire Web in search of a "Token session in URL" vulnerability, the objective is to set the cookie to through a GET request from the URI for example:

GET /index.html;vuln=</script></script>alert(1)</script> HTTP/1.1
Host: www.vulnerable.com Accept-Encoding: gzip, deflate Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64;
Trident/5.0) Connection: close

Basically if this had worked we would have two vulnerabilities, the first is the sending of sensitive information through a GET method, Burp calls it "Session Token in URL", on the other hand if it is possible to set the cookie through a GET , we would be talking about "Session Fixation" vulnerability. However, this vulnerability could not be exploited since it was not possible to set the value of the parameter vuln of the cookie. On the other hand, we do not compromise any endpoint nor can we make the user navigate through a proxy, so the only option we have is through a third party. That is to say, for the effective exploitation of this vulnerability, a domain external to the organization is required to be redirected to the domain of the organization and the XSS can be exploited.

Once this is understood, there are several vectors of attack:

1) Attach an HTML to a malicious email with the aim of the user to download it, and click on the link (method more tedious) since as we know it is not possible to insert JavaScript code in an email, at least in the managers (eg, Outlook, Gmail ...)

2)Create a page controlled by you, which redirect and set the cookie to the domain of the organization (simpler option than the previous one)

3) As it turned out, the page was also vulnerable to attacks by Clickjacking, therefore this vulnerability could be used to redirect to the domain of the organization.

An example of the code that could be used to exploit this vulnerability through a third party could be the following:

"<a href="https://www.vulnerable.com" id="ref">
$("a#ref").bind("click", function() {
$.cookie("vuln", "</script></script>alert(1)</script>");
});"

In no case is the web console of the user to be compromised, so in my opinion these types of vulnerabilities are not considered Self-XSS type, it would be something like DOM XSS based attacks, 4 example a XSS Indirect Reflected.

What do you think?

Thks.