Secure Programming Tips Week 2: Application Error Handling
As developers, we become so preoccupied with ensuring our applications work as designed that we often overlook the necessity of unit testing with regard to error handling. For example, if I am passing an ID to another page similar to the example below,
|
http://mysite.com/Details.asp?ID=1
|
I may test this link twenty times to ensure the Details.asp page populates correctly according to the ID value that has been passed. However, I may not even consider testing if the value passed in the ID parameter were something other than a number. After all, a number is what the code expects. So what would happen if we changed the value of the ID parameter from the number 1 to the letter a? Well, if we were doing proper error handling it should error gracefully and the user would be notified that the value supplied was incorrect. On the other hand, if proper error handling wasn’t implemented the user might get the following error:
|
Microsoft VBScript runtime error ‘800a000d’
Type mismatch: ‘[string: “a”]’
|
The primary problem here is we are expecting one type of input, and we aren’t performing proper validation and error handling in the event the type passed is different then what was expected. The above error occurs because the code is expecting a numeric value, but instead receives a string value. The developer wrote the code to expect a number, but didn’t take into consideration the possibility that another type might get passed. Issues like these are easy to remediate. Simply by adding some additional code to validate the type that was passed, such as the code below, the developer could mitigate the risk of the application failing in such an unexpected manner.
|
strValue = Request.Querystring(“ID”)
If IsNumeric(strValue) Then
Call ProcessDetailsPage(strValue)
Else
Response.Redirect(“ErrorPage.html”)
End If
|
The above code, when implemented, would check to ensure the value passed in the ID parameter met the criterion of being a numeric value. If the validation determined the value was non-numeric, it would then redirect the user to the Error.html page, where a message could be displayed informing the user that the value passed was incorrect.
There are occasions where improper error handling can become a major security risk. For instance, assume we pass the letter “a” in the ID parameter as above, but instead of a “Type mismatch” error the user receives the following message:
|
[SQLServer ODBC Driver][SQLServer]Invalid column name ’a’.
|
For those of you who are unfamiliar with it, this type of error message reveals to the user that the application is vulnerable to a SQL injection attack. If this error message were displayed to a malicious user he would have all the information he needs to begin specific targeted attacks against the application. Other types of application error messages that might be used by a malicious user include exposing internal server paths, exposing request headers (i.e. HTTP Referrer, User-Agent, etc.) in the error message, which could be used in an XSS (Cross-Site Scripting) attack or the dump of a stack trace that discloses intimate details about the application’s internal processes.
Most languages today are capable of handling errors at the application level. For example, ASP and ASP.NET both contain Application_OnError events within their global.asa and global.asax files, respectively. Below is an example of how global error handling in the global.asax or global.asax.vb file might look in an ASP.NET application.
|
Sub Application_Error(ByVal sender As Object, ByVal e As EventArgs)
Logger.Log(Server.GetLastError())
Response.Redirect(“ErrorPage.html”)
End Sub
|
When an application error occurs, the above code would log the error to our application log for later analysis. It would then redirect the user to our custom error page, thus preventing the possibility of sending a message to the user that might contain sensitive information, such as one that could inform the user that the application is vulnerable to a specific type of attack. Unfortunately, a lot of developers do not implement proper error handling techniques, but just remember global error handling is your friend, and when implemented properly can be a valuable tool in protecting your application from exposing sensitive information to outsiders.
Thanks, I hope you found this article useful! Please post any comments if you have questions.