URL Encoding/Decoding Flaw Mechanism in ASP.Net[1.0 - 2.0] Based Web Applications.

View Specific



zeroknock [at] secniche.org


For Education Purposes Only!


Analytical View.

The penetration of web leads to origin of some new artifacts.This in turn helps in understanding the weaknesses and flaws persist in the web applications that lead to origin of exceptions.These exceptions leverage lot of information regarding web application code , debugging parameters , stack traces etc. If these exceptions are not handle in a right way then it results in generation of attack base. The web works in fused way from developer point of view. There are two things that comes to mind

[1] Availability of Services
[2] Services with Secure Parameters.

The stress has been laid more on the availablity by the developers leaving behind the security paradigm. This has really enhanced the attack vector and poor development layout from security point of view. The attackers are always ready to attack where ever they found the weak spot. The point of talk is insecure coding has intensified the attack vector.Even the development languages provide modular inbuilt functions to reduce this effect of insecurity from the web applications but human malfeasance still persists.

The issue of talk is the URL flaw mechanism in ASP.Net based web applications.Even after modular security is applied but still the vector persists.
The most of the web applications are flaw prone due to coding errors.After lot of security concerns , still the developers lacking the art of producing good web applications. According to my analysis some part of developer community understanding the Art of Secure Coding . But on the contrary there are other developers who are not paying attention to this security aspect. Atlast the protections is all yours.

This talk adheres to the URL flaw in ASP.net coding that leads to exception generation.Now I am going to discuss the lack of secure coding leads to error prone web applications from security point of view. The talk is crucial because even after sanitization of secure parameters injections are still occuring.Lets see the handling of URL strings mechanism of ASP.Net. Even ASP.Net provides some system functions to resolve and handle the strings passed but a majority of web applications dont inherit the right layout. Lets see the way implementation of URL's are done.

	The HTTPModule provides specific functions for URL encoding and decoding. It too provides the:
[1] HtmlEncode and HtmlDecode functions to handle the HTML requests. [2] UrlEncode and UrlDecode functions to handle the strings passed as a URL to server.
Example:
UrlEncode %3cscript%3ealert%28%u201cHa%20ha%21%20We%u2019ve%20attacked%20your%20site%21%u201d%29%3c%2fscript%3e Lets look at the code how these modules are designed. How HtmlEncode is implemented internally.
public static void HtmlEncode(string s, TextWriter output) { char ch1; char ch2; int num3; if (s == null) return; int num1 = s.Length; int num2 = 0; while ((num2 < num1)) { ch1 = s.Chars[num2]; ch2 = ch1; if (ch2 != '\"') { if (ch2 == '&') goto Label_0064; switch ((ch2 - '<')) { case 0: output.Write("<"); goto Label_00AE; case 1: goto Label_0071; case 2: output.Write(">"); goto Label_00AE; } goto Label_0071; } output.Write("""); goto Label_00AE; Label_0064: output.Write("&"); goto Label_00AE; Label_0071: if ((ch1 >= ' ') && (ch1 < '\u0100')) { num3 = ch1; output.Write(string.Concat("&#", num3.ToString(NumberFormatInfo.InvariantInfo), ";")); } else output.Write(ch1); Label_00AE: num2 += 1; } }
This is the way how the system fucntions is implemented. Even I dont find it so secure and reliable way to encode and decode the HTML data. the URLEncode is based on this too.Lets look at the implementation as a web module.
	
			Option Strict On
			Option Explicit On
	
			Imports System
			Imports System.Windows.Forms
			Imports System.Drawing
			Imports System.Web
	
			Public Class WinApp
	    		Inherits System.Windows.Forms.Form
	
	    			private m_url as TextBox
	
	    			<STAThread()> _
	    		Shared Sub Main
	        		Application.Run(new WinApp())
	    		End Sub
	
	   		 Public Sub New
	        		Me.Text = "URL Test"
	
	        		m_url = New TextBox()
	        		m_url.Size = new Size(280,30)
	        		m_url.Location = new point (5,5)
	
	        		Controls.Add(m_url)
	        		m_url.Text = "http://www.microsoft.com?value="; & HttpUtility.UrlEncode("String To Encode.")
	    		End Sub
	
			End Class
	
	Just an implementation view.
	
I have worked over this. I have tested applications based on this concept exactly where these modules are implemented. No doubt the string gets converted to required pattern. Lets see what I have observed in many of applications.I am enumerating the kind of exceptions as snapshots so that one can have desired look at the stack traces. These all exceptions have occured after the conversion of parameters.

[ XPath Exception Trace || /articles.aspx?id=')%3C%3E']



[ Format String Exception || dce.aspx?sid=')%3C%3E%3C%3E']


[ Invalid Cast Exception || Details.aspx?Entry=');%3C%3E';]


[ Null Object Reference Exception || /get/est.aspx?est=''%3C%3E';]


These are some of the exceptions that occur even after the encoding of URL through generic system functions. There are lot of other exceptions like SQL exceptions etc occur due to this. The point comes , where actually the infection occurs.In some circumstances, unhandled exceptions can force the ASP.NET worker processes to shut down. In this instance a fresh worker process is loaded, the application is restarted and application and session state can be lost depending on the configuration. Also, if the application relies on session state to store authentication information and the application is configured to use in-process sessions, the user may be logged out. ASP.NET 2.0 produces markup that passes W3C validation, but it is debatable as to whether this increases accessibility.Lets look at the model of ASP.net functioning.





The model predicts the complete functioning of request that are sent to server through asp.net web pages. The infection , from the above given examples can be traversed in any direction leading to crash of application or mal functioning that causes service problems.The problem occurs as usual.The cause is described below.

The false impression is that once encoding is done no other security steps are required in accomplishing the task.But that not happen exactly.The problem is mainly this encoding mechanism does not ensure the reliability in handling the strings that are passed through URL placed in browser window.Here I am explaining two approaches together which can circumvent thess type of flaws in web applications.The list is underlined as:

[1] Modular Checks : This is the first practise that need to be undertaken after the system functions are applied for security checks in web application.These are called to be as passive security because these functions are designed by developers for application security.These are not compared with system functions like encoding/decoding.A fex examples have been stated underlined.
		if (Request.QueryString["id"] != null)
		{
			  // Do something with the querystring
		}
		
		
		
		if (!String.IsNullOrEmpty(Request.QueryString["id"]))
		{
		  	// Do something with the querystring
		}
	
		So we do the check again more thoroughly:
		
		
		if (!String.IsNullOrEmpty(Request.QueryString["id"]) && Request.QueryString["id"].Length == 5)
		{
		  // Do something with the querystring
		}
		
	
These checks are also termed to be as Passive Filters.This is also an effective way of imparting security.

[2] Anti XSS Libraries : This is also one of the finest approach because these libraries provide and rendered the specification of XSS parameters in the form of functions.The modules defined predominantly checks the input parameters against any rogue input string injected in it.The concept of libraries is getting intensified.So this is also good practise of security if stress has to be laid on the web application coding.

The specific anti-XSS counter-measures are controlled by two options under NoScript Options|Advanced|Additional restrictions for untrusted sites:

1. Sanitize cross-site suspicious requests - potentially dangerous characters, why may be used to inject malicious JavaScript code, are stripped out from both the URL and the REFERER header.

2. Turn cross-site POST requests into data-less GET requests - the request is sent but no malicious data is uploaded.

Both these options are enabled by default for your maximum protection. NoScript's anti-XSS filters had been deeply tested and proved their ability to defeat every known reflective XSS technique, but their power is a double-edged sword: sometime they may detect a weird looking but legitimate request as a "potential XSS attempt

[3] Inline Redirection of Error Pages : This is some what kind of security based on error handling. In this a concept of inline redirection is used.This means if an error persists in the web application and it has been undertaken then how to handle it dynamically is the perspective of this approach.The page is internally redirected to articulated response page that holds only generla information of error. If this mechanism wont work well than lot of information is leveraged in the form of stack traces or configuration information etc.

If any of the vector does not applied in a stringent manner then injections will occur throwing off the security of websites.some web applications are written to (sometimes optionally) operate completely without the need for client-side scripts. This allows users, if they choose, to completely disable scripting in their browsers before using the application. In this way, even potentially malicious client-side scripts could be inserted unescaped on a page, and users would not be susceptible to XSS attacks. Unfortunately external content can still be loaded into the page with tags like [iframe] or [object], which often is enough to trick users.

So all in all this has to be encountered in a generic way otherwise the vector go on flourishing.