Microsoft Internet Information Services Cross Site Scripting

Microsoft Internet Information Services web server suffers from a cross site scripting vulnerability.

MD5 | b0f6fb58b98a9bb87128e9627306c115

Cross Site Scripting / HTML injection vulnerability in Microsoft
Internet Information Services web server


Versions Affected:

MS Internet Information services (All platforms and versions)


CVE Reference:



Vendor Fix:

Microsoft released bulletin MS017-16 and associated patches for each
affected version



The default HTTP 500.19 error page of Internet Information Services
fails to properly sanitize user-supplied input as rendered in the path
where the Web.config file of the application or directory was
attempted to be loaded.

Under normal conditions, any attempt to craft and visit an URL
including javascript or html content on it will trigger either an HTTP
400 response from the server or will be handled by the customErrors
Web.config setting of the application. It was discovered that, if a
website root hosted on IIS or any subfolder on it is located in a UNC
path (NAS, shared folder or mapped drive), it is possible to craft a
special link that, upon clicked, will trigger an HTTP 500.19 error
page from the server rendering the javascript or html code injected as
part of the path where the Web.config file was attempted to be loaded.

As the flaw lies in the fact of the improper sanitization of the
500.19 error page, other attack vectors not requiring UNC paths might



By inducing a victim to click on a specially crafted link, is possible
to execute javascript code in the victimas browser in the context of a
website hosted on IIS to conduct a classical reflected Cross Site
Scripting (XSS) attack. The impact could be stealing user cookies,
hijacking user session or performing unauthorized actions in the web
application on behalf of the victim.

If the code injected is HTML, the vulnerability allows to conduct
phishing attacks using the legitimate website against web application


Proof of concept:




Neither ValidateRequest nor configuring customErrors setting on
Web.config will protect from this flaw, as this happens earlier in the
request processing pipeline.



Best regards,

David Fernandez

Sidertia Solutions S.L.

Related Posts