Skip Navigation

  • Home
  • Contact us
  • FAQ
  • Glossary
  • Public key
  • Sitemap
  • Cymraeg
  • What's new
CPNI - Centre for the Protection of National Infastructure

Advanced search

  • About CPNI
  • The threats
  • Security planning
  • Methods of attack
  • Protecting your assets
  • Products and services
    • CSIRTUK advisories
      • Advisories archive
    • General protective security publications
    • InfoSec briefings
    • InfoSec technical notes
    • InfoSec vulnerability disclosures
    • Good practice guidelines
    • Viewpoints
    • Information exchanges
    • Risk Management Delivery Group
  • Research
Home > Products and services > CSIRTUK advisories > Advisories archive > October 2006 > NISCC Vulnerability Advisory 165746/NISCC/DOTNET

October 2006

NISCC Vulnerability Advisory 165746/NISCC/DOTNET

ID: 00711
Ref: 682/2006
Date: 20 October 2006:15:12:26
Version: 1

Title: NISCC Vulnerability Advisory 165746/NISCC/DOTNET
Abstract: The NISCC Vulnerability Team has released a new advisory regarding a vulnerability in Web applications coded in any .NET language which rely only on the inbuilt .NET request filtering.
Vendors affected: NISCC
Operating systems affected: NISCC
Applications affected: NISCC


Security Implications of failing to correctly use filtering in .NET web applications

Version Information

Advisory Reference 165746/NISCC/DOTNET
Release Date 20/10/06
Last Revision 12 October 2006
Version Number 0.1

Acknowledgement

ProCheckup (http://www.procheckup.com) passed us specific details of a number of possible attack vectors which bypass the inbuilt .NET request filtering.


What is Affected?

Web applications coded in any .NET language which rely only on the inbuilt .NET request filtering.

The following combination of client and server environment was tested and found to be vulnerable:

* Microsoft Windows Server 2003 Standard Edition Build 3790.srv03_sp1_rtm.050324-1447 Service Pack 1
* Microsoft IIS 6.0
* Microsoft ASP .NET Framework Version 2.0.50727.42
* Microsoft Internet Explorer 6.0.2900.2180.xpsp_sp2_gdr.050301-1519
* Microsoft Internet Explorer 7.0.5450.4 Beta 3


Severity

Varies, depending on application and how user input is processed.

#Phishing# redirect attacks, and session hijacking through cookie theft were successfully reproduced in the test environment.

These attacks would be possible provided a server-side application solely relies on .NET request filtering for sanitizing input parameters that are echoed back to the web browser.

Other attacks such as HTML injection and SQL injection may also be possible.


Summary

Applications which fail to provide their own filtering on top of the .NET filtering may be vulnerable to a number of different attacks. For example, this could include SQL injection or client side XSS.

Do not solely rely on ASP.NET request validation. Treat it as an extra precautionary measure in addition to your own input validation.

Microsoft is aware of these implications and have provided some best practices in the 'Solutions' section of this advisory.


Details

Details of a number of ways to bypass security in an application where only the .NET filtering is used were provided by ProCheckup. These will be made available at a later date by ProCheckup at http://www.procheckup.com.

Effective filtering includes more than simply scanning for #known bad# input. For example, if an input field is expected to be numeric then only the characters 0 to 9 should be allowed. Where an input field is for a first name, constraints could be placed on length and possible characters.

The .NET framework provides the relevant classes which enable a programmer to specify constraints on input and manipulate output so that it does not contain potentially harmful characters. Wherever user input is accepted into a web application, these should be used.

Additionally, secure programming practices should be adopted elsewhere in an application. For example, where database connectivity is required there are classes to handle the connection and any queries in a secure manner.


Solution

Microsoft provides a number of articles concerning safe programming in the .NET environment. These articles specifically state that the .NET filtering is not sufficient on its own to completely protect an application.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/securitybarriers.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/paght000003.asp

http://msdn2.microsoft.com/en-us/library/system.web.httprequestvalidationexception.aspx


There are a number of third party websites which also cover security in .NET, such as OWASP.

http://www.owasp.org/index.php/Category:OWASP_.NET_Project


In addition, books on secure coding are available from both Microsoft and independent press.


Vendor Information

The Microsoft Corporation is a multinational computer technology corporation and has offices in over 100 countries. Headquartered in Redmond, Washington, USA, its most popular products are the Microsoft Windows operating system and the Microsoft Office suite of productivity software.

For more information about Microsoft, please visit http://www.microsoft.com/


Credits

The NISCC Vulnerability Management Team would like to thank ProCheckup for reporting these issues to NISCC and Microsoft for their assistance in outlining the solutions recommended to address them.


  • Accessibility |
  • Terms and conditions |
  • Privacy statement |
  • Data protection act |
  • Freedom of information |