IIS Security

IIS 4 and IIS 5 were affected by the CA-2001-13 security vulnerability which led to the infamous Code Red attack;[52][53] however, both versions 6.0 and 7.0 have no reported issues with this specific vulnerability.[54] In IIS 6.0 Microsoft opted to change the behaviour of pre-installed ISAPI handlers,[55] many of which were culprits in the vulnerabilities of 4.0 and 5.0, thus reducing the attack surface of IIS.[53] In addition, IIS 6.0 added a feature called "Web Service Extensions" that prevents IIS from launching any program without explicit permission by an administrator.

By default IIS 5.1 and earlier run websites in a single process running the context of the System account,[56] a Windows account with administrative rights. Under 6.0 all request handling processes run in the context of the Network Service account, which has significantly fewer privileges, so that should there be a vulnerability in a feature or in custom code it won't necessarily compromise the entire system given the sandboxed environment these worker processes run in.[57] IIS 6.0 also contained a new kernel HTTP stack (http.sys) with a stricter HTTP request parser and response cache for both static and dynamic content.[58]

According to Secunia, as of June 2011, IIS 7 had a total of six resolved vulnerabilities while[54] IIS 6 had a total of eleven vulnerabilities, out of which one was still unpatched. The unpatched security advisory has a severity rating of 2 out of 5.[54]

In June 2007, a Google study of 80 million domains concluded that while the IIS market share was 23% at the time, IIS servers hosted 49% of the world's malware, the same as Apache servers whose market share was 66%. The study also observed the geographical location of these dirty servers and suggested that the cause of this could be the use of unlicensed copies of Windows that could not obtain security updates from Microsoft.[59] In a blog post on 28 April 2009, Microsoft noted that it supplies security updates to everyone without genuine verification.[60][61]

The 2013 mass surveillance disclosures made it more widely known that IIS is particularly bad in supporting perfect forward secrecy (PFS), especially when used in conjunction with Internet Explorer. Possessing one of the long term asymmetric secret keys used to establish a HTTPS session should not make it easier to derive the short term session key to then decrypt the conversation, even at a later time. Diffie–Hellman key exchange (DHE) and elliptic curve Diffie–Hellman key exchange (ECDHE) are in 2013 the only ones known to have that property. Only 30% of Firefox, Opera, and Chromium Browser sessions use it, and nearly 0% of Apple's Safari and Microsoft Internet Explorer sessions.[62]