Microsoft's Broken Security Site

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Is anyone surprised that Microsoft ignored this principle ?

Details

Between April 1999 and February 2000, the Microsoft Security Advisor website was broken. I notified the Microsoft Webmaster <webmaster@microsoft.com> on 19 June 1999 and the Microsoft Security Team <secure@microsoft.com> on 21 October 1999.

Attempts to retrieve the website during this period returned the following.


    Microsoft VBScript runtime
    error '800a000d'

    Type mismatch: 'CInt'

    /security/inc/scripts.txt, line 279

Analysis

Upon reading the broken script, I find that Microsoft were invoking CInt() on the ninth character of HTTP_USER_AGENT, that is, Microsoft are assuming that the ninth character will be a digit, as follows.


    CInt(Mid(Request.ServerVariables("HTTP_USER_AGENT"),9,1))

According to section 14.43 of the HTTP/1.1 standard, this assumption is invalid. Microsoft's script was so broken that even if you used the example given in this standard, their server would report the same error.

The "corrected" version of the script makes the same assumption; however, it now resumes processing instead of reporting the error, as follows.


    On error resume next
    CInt(Mid(Request.ServerVariables("HTTP_USER_AGENT"),9,1))

Impact

To see a list of the hundreds of browsers that the Microsoft site would have crashed and burnt on, go to Dave Garaffa's Browser Watch site. Remember, if the ninth character is anything other than a number, Microsoft's site would have failed with the "VBScript runtime error" above.

Microsoft's site worked with Internet Explorer and Netscape, but not with many other browsers, such as Lynx.

I should stress that this problem was not the fault of any browser and was totally the fault of Microsoft, specifically, the author of the script that Microsoft's Security site relies on.

Time line

I've created the following time line of my efforts to have this minor error corrected. These are only the significant events - I've omitted many of the unanswered emails that I've sent.

28 Apr 1999: The script is updated. This is the version that exhibits the problem described herein.
18 Jun 1999: The Microsoft Webmaster <webmaster@microsoft.com> is notified.
28 Jul 1999: The Microsoft Webmaster <webmaster@microsoft.com> replies, saying, "This page has been recently recoded," and that the problem no longer occurs.
29 Jul 1999: The Microsoft Webmaster <webmaster@microsoft.com> replies again, saying that the "page owner" wants my assistance.
30 Jul 1999: I reply, advising that they use the World Wide Web Consortium's HTML Validation Service.
5 Aug 1999: The "page owner" replies claiming to have a new test script that passes the W3C Validator. The page has exactly the same problem as the original and does not pass the W3C Validator.
6 Aug 1999: I reply, advising that the test page has not in any way corrected the error.
27 Aug 1999: I contact Microsoft Australia Technical Support; however, all they are able to do is suggest that I email the Microsoft Webmaster <webmaster@microsoft.com> again. I send another email.
21 Oct 1999: The Microsoft Security Team <secure@microsoft.com> is notified.
21 Oct 1999: The Security Team reply, saying, "I'll work with our web folks and see that the necessary changes are made. Sorry for the inconvenience."
26 Oct 1999: I query the Security Team for an estimated date for the completion of the changes.
26 Oct 1999: The Security Team reply, saying, "I can't say for sure how long the changes will take," and, "we are pushing to get the changes made as quickly as we can. Thanks for your patience."
12 Nov 1999: I send a fax to the Customer Relations Manager, Microsoft, Australia, outlining the problem and requesting that the site be fixed.
16 Nov 1999: I'm told that the issue has been escalated and that I should expect a response in 5-7 working days.
23 Nov 1999: It's now been escalated even higher and they will contact me tomorrow.
24 Nov 1999: Microsoft inform me the issue has been "escalated to Redmond"; however, they were unable to provide a ETA on a response.
30 Nov 1999: Peter Cray <peterc@microsoft.com> is now handling the escalation to Redmond; however, he can provide no additional information at this time.
1 Jan 2000: A new year and Microsoft's Security site is still broken ... Perhaps by the next millennium they might have fixed it. I'm not certain :-)
31 Jan 2000: The script is updated. This is the "corrected" version described above.
3 Feb 2000: The Microsoft Webmaster <webmaster@microsoft.com> replies to inform me that the site has been corrected.

Conclusion

This was a relatively small issue and, paradoxically, my effort was in inverse proportion to Microsoft's.

What hope would anyone have with a larger issue given it took nine months to obtain a twenty character fix to their public website ?