(A short tut for my first day back since 2004....)

One of the most often over-looked and greatest invitations to exploit your website is the lack of proper error handling. Most websites these days have at least some component of them which is database (db) driven. Whether you are using Coldfusion (CF) (my app of choice), PHP, ASP, JSP's or ...whatever, if you don't have effective error handling, you are just asking for trouble.

So you say...what's the risk. Make a customer angry? Sure. If your site is blowing up from poor coding for your -expected- user, well, maybe you should hire someone who knows what they are doing. What we are most concerned with is the malicious user who will attempt to throw errors on purpose to see if they can determine some key information about your site.


Data Validation

Most webdesigners know that validation is critical to maintain your data integrity. What many forget is that you need to do both client and server side validation. Lots of folks will do some form of javascript validation to ensure that users complete forms as intended. It is important to note that this type of validation is for <convenience only>. There is <no security> from client side validation. Sure, you can prevent Joe User from submitting your form without an email field filled in, but this does nothing to stop the malicious user who looks at the source, modifies your post data and submits some nasty code to your app server.

For these examples, we are going to pretend client side validation doesn't exist (since we now know that it is only for convenience and not security) and that there is no error handling on the server side. The error message here is generated by Coldfusion. Other applications will have their specific quirks but the data exposed is similar.

What we can discover simply by not filling in a form field.


Error Executing Database Query.
[Macromedia][SequeLink JDBC Driver][ODBC Socket][Microsoft][ODBC Microsoft Access Driver] Syntax error (missing operator) in query expression 'disposition

<we now know that the database being used is MS Access>


The error occurred in C:\Inetpub\wwwroot\testing\work\groupcount.cfm: line 4

<we now know physical file path>


2 : select distinct Disposition
3 : from demo
4 : where disposition = #form.blah#
5 :
6 : </cfquery>

SQL select distinct Disposition from demo where disposition =

<we know now the sql behind the form>

DATASOURCE testing

<we now know the data source name>

Each one of these exposed bits can potential give a malicious user the information they need to compromise your data or potentially <own> your server.


FYI... In CF, the server side validation for blank form fields is simple

<cfif form.blah eq ""> if the form.blah field is ""
<cflocation url="formpostpage.cfm"> redirect the user back to the calling page
</cfif>


What could we do with some <nasty code>

just about anything...see http://www.google.ca/search?q=sql+injection (If this bit of reading doesn't get you doing server side validation I don't know what will)


What we can do by modifying urls

For fun, try this on your site http://localhost/testing/work/? You might be surprised what you see

Many malicious users try to guess webserver paths simply by modifying url strings and submitting them. A generic error page is going to be a lot harder to get useful information from. <important> If you have areas which require login protection, make sure you have some kind of access control which doesn't allow access via modified urls.

Of course, while server side validation is <really> important, it might not account for all possible situations.

More to the point of this article, with proper error handling you can prevent a lot of sensitive information from being exposed.

In CF error handling is a piece of cake...

<cferror type="ANY" template="errorhandler.html" mailto="webmaster@somesite.com">
With any error that occurs, the user sees errorhandler.html and an email is sent to the webmaster. This means that the user sees a nicely formatted page (which makes you look professional), no sensitive data is exposed (which makes you more secure) and you get notified (of either a coding issue or a possible attack)

Other languages will vary in complexity for error handling code but the important point is to <have> some.

This is not to say that you just need effective error handling. Error Handling <and> server side validation are the key to a happy day in web land.