lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 29 Nov 2014 18:17:24 -0800
From: waysea <>
Subject: Re: [FD] XSS (in 20 chars) in Microsoft IIS 7.5 error message

If you can get a <script> tag in (usually the very first tag to be 
blacklisted), you could
1. register a two character domain with a two character TLD (all the 
single character domains with two letter TLDs had been taken the last 
time I checked)
2. have the root page be an index.js file (instead of index.html)
3. use something like:

A) <script src=//>
B) <script/src=//>

Without knowing more about your specific situation, either of the above 
*_should_* work as HTML parsers are usually very lenient on what they 
allow. So:
1. There doesn't usually need to be a close script </script> tag.
2. After declaring a src, any text that might be inline JavaScript is 
3. Immediately after the tag name declaration, the / character can be 
used in place of a space (but not for any other attributes after that).
4. By starting off with // in the src definition, the parser will simply 
use whatever protocol (http or https) the current page is on and 
automagically insert it into the script request.
5. As you already know, the HTML parser doesn't need to have the 
attribute value enclosed in ' or " characters, and will see the > 
character as the end of the tag, not part of the attribute value.

Of course, if the DOCTYPE is XHTML instead of HTML, then some of the 
above is no longer valid.

If you don't want to register a domain, the guy that owns 
has that setup already in place and is usually cool about people using 
that in their proof of concepts as long as you send an email beforehand 
stating what you're doing with it (see It is http 
only at the moment (no https yet), so if your error page is over https 
then mixed content rules may come into play and prevent the script from 

On 11/27/2014 10:35 AM, A Z wrote:
> Hello everyone,
> I found some weird HTML code injection in an IIS error message. IIS spits
> out some part of the user input that generated the error message, but will
> only display 20 characters at most.
> My question is: is it possible to actually exploit an XSS with this ?
> Here is an example:
> HTTP Request: mypage?search=%3cb%20onclick%3dalert(1)>%3e
> HTTP Response (real):
> <p>An error has occured.</p>
>      <p>Exception HttpRequestValidationException occurred while attempting
> <b>mypage</b></p>
>      <p>Exception message is: <b>A potentially dangerous Request.QueryString
> value was detected from the client (search="<b
> onclick=alert(1)>...").</b></p>
>      <p>Stack trace:</p>
>      <pre>
> Server stack trace:
> [..]
> My payload was: <b onclick=alert(1)>> and it works (after clicking).
> However, can this actually be exploited in real life ? I tried stuff in 20
> characters like: <embed src=http://x> or <img src=http://x/z> but no luck.
> Has anyone ever tried this before ?
> Thanks,
> P.S. This might be a silly question with an obvious answer. If so, I'd be
> grateful to have some extra information (links, docs etc.).
> _______________________________________________
> Sent through the Full Disclosure mailing list
> Web Archives & RSS:

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists