The information has been provided by Microsoft Security Bulletin.
The original article can be found at: http://www.microsoft.com/technet/security/bulletin/ms06-056.mspx
* Microsoft Windows 2000 Service Pack 4
* Microsoft Windows XP Service Pack 1 or Windows XP Service Pack 2
* Microsoft Windows XP Professional x64 Edition
* Microsoft Windows XP Tablet PC Edition
* Microsoft Windows XP Media Center Edition
* Microsoft Windows Server 2003 or Microsoft Windows Server 2003 Service Pack 1
* Microsoft Windows Server 2003 for Itanium-based Systems or Windows Server 2003 with SP1 for Itanium-based Systems
* Microsoft Windows Server 2003 x64 Edition
* Microsoft .NET Framework 2.0 Download the update
* Microsoft .NET Framework 1.0
* Microsoft .NET Framework 1.1
Mitigating Factors for .NET Framework 2.0 Cross-Site Scripting Vulnerability:
* In a Web-based attack scenario a compromised Web server an attacker could inject a client side script in the user's browser. The script could spoof content, disclose information, or take any action that the user could take on the affected web site. Attempts to exploit this vulnerability would require user interaction.
* By default, .NET Framework 2.0 controls do not set the AutoPostBack property to true.
Workarounds for .NET Framework 2.0 Cross-Site Scripting Vulnerability:
Microsoft has tested the following workarounds. Although these workarounds will not correct the underlying vulnerability, they help block known attack vectors. When a workaround reduces functionality, it is identified in the following section.
* On computers running .NET Framework 2.0, do not set the AutoPostBack property for controls on a page to true :
* On computers running .NET Framework 2.0 AutoPostBack is a property of controls on a WebForm. By default the AutoPostBack property is set to false. For more information, see Knowledge Base Article 328923.
FAQ for .NET Framework 2.0 Cross-Site Scripting Vulnerability:
What is the scope of the vulnerability?
A cross-site scripting vulnerability may exist in a server running a vulnerable version of the .Net Framework 2.0 that could inject a client side script in the user's browser. The vulnerability is within ASP.NET controls that set the AutoPostBack property to true . In a Web-based attack scenario a compromised Web site could accept or host user-provided content or advertisements which could contain specially crafted content that could exploit this vulnerability.
The script could take any action on the user's behalf that the Web site is authorized to take. This could include monitoring the Web session and forwarding information to a third party, running other code on the user's system, and reading or writing cookies.
What causes the vulnerability?
A cross-site scripting (XSS) vulnerability results from the way that .NET Framework 2.0 validates the value of an HTTP request.
What is ASP.NET?
ASP.NET is a collection of technologies within the.NET Framework that enable developers to build Web applications and XML Web Services.
Unlike traditional Web pages, which use a combination of static HTML and scripting, ASP.NET uses compiled, event-driven pages. This enables developers to build Web-based applications with the same richness and functionality usually associated with applications built in languages such as Visual Basic or Visual C++. Because ASP.NET is a Web-based application environment, it requires an underlying Web server to provide basic HTTP functionality. For this reason, ASP.NET runs on top of Internet Information Services (IIS) 5.0 on Windows 2000, IIS 5.1 on Windows XP, and IIS 6.0 on Windows Server 2003.
What is AutoPostBack?
AutoPostBack is a property supported by controls in a form. Forms using a control that supports this property can set the value of this property to true (the default value is false) which results in control posting back to the server each time a user interacts with the control.
What is cross-site scripting?
How does cross-site scripting work?
Web pages contain text and HTML markup. Text and HTML markup are generated by the server and are interpreted by the client. If untrusted content is introduced into a dynamic page, neither the server nor the client has sufficient information to recognize that this injection has occurred and to take protective measures.
What might an attacker use the vulnerability to do?
An attacker who successfully exploited this vulnerability on a server running a vulnerable version of the .Net Framework 2.0, could inject a client side script in the user's browser. The script could spoof content, disclose information, or take any action that the user could take on the affected web site. Attempts to exploit this vulnerability would require user interaction.
Who could exploit the vulnerability?
In an e-mail attack scenario an attacker could exploit the vulnerability by sending a specially crafted e-mail message to a user of a server that is running an affected software application. The attacker could then persuade the user to click a link in the e-mail message.
In a Web-based attack scenario a compromised Web an attacker could inject a client side script in the user's browser. The script could spoof content, disclose information, or take any action that the user could take on the affected web site. Attempts to exploit this vulnerability would require user interaction.
What systems are primarily at risk from the vulnerability?
Internet facing systems are primarily at risk from this vulnerability. In addition, internal Web sites that use ASP.NET to host sensitive data can be at risk from this vulnerability.
Could the vulnerability be exploited over the Internet?
Yes. An attacker could try to exploit this vulnerability over the Internet.
What does the update do?
The update removes the vulnerability by modifying the way that .ASP.NET validates the value of a HTTP request.
When this security bulletin was issued, had this vulnerability been publicly disclosed?
No. Microsoft received information about this vulnerability through responsible disclosure. Microsoft had not received any information to indicate that this vulnerability had been publicly disclosed when this security bulletin was originally issued.
When this security bulletin was issued, had Microsoft received any reports that this vulnerability was being exploited?
No. Microsoft had not received any information to indicate that this vulnerability had been publicly used to attack customers and had not seen any examples of proof of concept code published when this security bulletin was originally issued.