Browsers autocorret incorrect URL values in HTML

I have already described, that browsers autocorrect URL values in HTML document and MS browsers (IE and Edge) are in this term a bit different. Read first thise article: "Request URI, Query String and URL encoding" [1].

As one of examples, I described how this problem was in LinkedIn in 2013 "Reflected XSS in LinkedIn (in 2013)" [2].

Now, exactly the same problem was in [3].

Proof-of-Concept: Reflected XSS in

Pre-conditions and restrictions

Browser - attack works only with Internet Explorer.

Due to described limitations in previous article [1], it wasn't possible to use:

  • spaces or whitespace in general (Internet Explorer URL encodes whitespaces)
  • parameters for HTML elements (problematic to do those without spaces anyway)

Since Internet Explorer has built-in XSS filter there was a need to bypass it one also.


I found vulnerability from search functionality. Request URI, including search phrase, was presented in HEAD section:

<link rel="canonical" href="" />

If to make assumption, that Request URI is often presented there, then search functionality definetely is not the only affected place.

Attack code

Formated attack code:

<d "


  • "> close href value and link element to be able to start new HTML element
  • <asd>.. message ... </asd> - new element with message
  • <style> .. </style> - style for created element
  • <d " - starting new dummy element to take link tag "leftovers" (">) in use for nice output

As a HTML link

<a href='"><asd>What&nbsp;a&nbsp;surprise</as><style>asd{background-color:red;font-size:40px;padding:40px;color:white;height:100px;width:100%;position:fixed;top:200px;z-index:999;text-align:center;}</style><d "'>click me</a>

Result in the output visually: XSS - Proof-of-Concept

Feedback and status for listed problem

Feedback was fast. Problem is fixed.


Request URI and Query String etc are user input. And user input is always potentially malicious.

Vulnerability Disclosure Timeline

Timezone for dates: Tallinn/Europe

  • 2016-10-26 | me > | via web form - where I should send info about XSS? No response.
  • 2016-11-02 | me > | via email - where I should send info about XSS?
  • 2016-11-02 | > me | instructions
  • 2016-11-02 | me > | details about vulnerability
  • 2016-11-15 | > me | fixed, please confirm
  • 2016-11-15 | me > | seems ok
  • 2016-11-15 | me | Full Disclosure in blog



comments powered by Disqus