“ASPXErrorPath in URL” Technique in Scanning a .Net Web Application

For a long time that I have been using a simple technique whenever I scan a black-box .Net web application. Many of you may already know about this, but I could not find anything in writing and that is why I have decided to write about it and document it.

 

This is the scenario:

We have a .Net web application which redirects you to an error page whenever there is any error. The header and body of the responses from the server are exactly the same when the page is not there or there is an error in the page. And, we are interested to distinguish 404 (page not found error) and 500 (internal error) error codes from each other.

Here is an example:

1- The following file is available on the server:

http://www.sdl.me/PoCs/validfile.aspx

Note: It has an error when you do not provide its input (?input=1)

2- The following file is not available on the server:

http://www.sdl.me/PoCs/invalidfile.aspx

 

As there are some errors in both of these links, we are redirected to “http://www.sdl.me/pocs/error.html”.

Now, how can we detect which one is really on the server and what is the actual status code?

 

My Solution:

It is possible to add a “?aspxerrorpath=/” to both of these URLs to see the actual error. It is not still possible to see the source of error, but it will help us to make the crawling results more accurate.

Therefore, we would have:

1- http://www.sdl.me/PoCs/validfile.aspx?aspxerrorpath=/

2- http://www.sdl.me/PoCs/invalidfile.aspx?aspxerrorpath=/

 

Automated Scanners:

Web application security scanners such as Acunetix or Burp Suite Pro can also use this feature (bug?) for the .Net applications.

I have created a Burp Suite Extension as an example that will add “?aspxerrorpath=/” to the “.aspx” files in the scope:

/*
 * File Name: BurpExtender.java
 * Author: Soroush Dalili - @irsdl
 * Weblog: http://soroush.secproject.com/blog/
 * Date: 11 June 2012
 * Description: Quick extension for the "ASPXErrorPath in URL" technique
 * More Information:  http://soroush.secproject.com/blog/2012/06/aspxerrorpath-in-url-technique-in-scanning-a-net-web-application/
 */

package burp;
import java.io.UnsupportedEncodingException;
import java.net.URL;

public class BurpExtender 
{
	public burp.IBurpExtenderCallbacks mCallbacks; // I will use this to keep the callbacks
	public void registerExtenderCallbacks(IBurpExtenderCallbacks callbacks)
	{
		mCallbacks = callbacks;
	}
	public void processHttpMessage(
			String toolName, 
			boolean messageIsRequest, 
			IHttpRequestResponse messageInfo)
	{  

		if (messageIsRequest){
			try
			{
				URL uUrl = messageInfo.getUrl();
				if (mCallbacks.isInScope(uUrl) && uUrl.getFile()!=null)
				{
					if(uUrl.getFile().matches("(?im).*\\.as[\\w]x$"))
					{
					String[] requestHeaderAndBody = {"",""};
					String finalRequestHeaderAndBody;
					requestHeaderAndBody = getHeaderAndBody(messageInfo.getRequest());
					requestHeaderAndBody[0] = requestHeaderAndBody[0].replaceAll("\\.aspx[\\?]*", ".aspx?aspxerrorpath=/&");
					finalRequestHeaderAndBody = requestHeaderAndBody[0]+"\r\n\r\n"+requestHeaderAndBody[1];
					messageInfo.setRequest(finalRequestHeaderAndBody.getBytes("UTF-8"));
					}
				}
			}
			catch (Exception e)
			{
				e.printStackTrace();
			}
		}

	}

	// Split header and body of a request or response
	private String[] getHeaderAndBody(byte[] fullMessage) throws UnsupportedEncodingException{
		String[] result = {"",""};
		String strFullMessage = "";
		if(fullMessage != null){
			// splitting the message to retrieve the header and the body
			strFullMessage = new String(fullMessage,"UTF-8");
			if(strFullMessage.contains("\r\n\r\n"))
				result = strFullMessage.split("\r\n\r\n",2);
		}
		return result;
	}

}

 

Recommendation for the developers/website administrators:

In order to stop penetration testers to use this technique, you need to stop or rewrite any web request which has “aspxerrorpath” parameter and its destination is not the default error page.

For example, in IIS7 (when your error page is “error.aspx”) we can use the following “web.config”:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<system.web>
		<customErrors mode="On" defaultRedirect="error.aspx" />
	</system.web>
	<system.webServer>
		<rewrite>
			<rules>
				<rule name="Query String Rewrite">
					<match url=".*\.as[\w]x" />
					<conditions>
						<add input="{QUERY_STRING}" pattern=".*aspxerrorpath=.*"
							negate="false" />
						<add input="{REQUEST_FILENAME}" pattern="error.aspx" negate="true" />
					</conditions>
					<action type="Redirect" url="error.aspx" appendQueryString="true" />
				</rule>
			</rules>
		</rewrite>
	</system.webServer>
</configuration>

For more information about IIS7 URL Rewrite please visit: “http://learn.iis.net/page.aspx/664/using-url-rewrite-module-20/

About Soroush Dalili
Web application security pentester.

2 Responses to “ASPXErrorPath in URL” Technique in Scanning a .Net Web Application

  1. AbiusX says:

    Nice post but the amount of hatred I have for ASPX prevents me from taking this seriously :D

  2. Michael says:

    Great burp extension, certainly speeds up enumeration quite dramatically, especially during during larger web application penetration testing projects.

    Michael – D1s