It's the errors stupid...
Results 1 to 3 of 3

Thread: It's the errors stupid...

  1. #1
    Senior Member
    Join Date
    Jan 2002
    Posts
    682

    It's the errors stupid...

    (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.
    I used to be With IT. But then they changed what IT was. Now what I'm with isn't IT, and what's IT seems scary and weird." - Abe Simpson

  2. #2
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    I already use something similar in my own applications running in PHP and ASPNET.

    The only problem really is these horrible legacy applications written in ASP, where there is no scope for setting an application-wide error handler. There is not even any way of getting a stack trace out of ASP (unless you happened to have the debugger attached to the process *at the time().

    But in our PHP and ASPNET apps, yes, the end-user sees a custom error page, and our support staff see a stack trace.

    There is one little tip I would give you:

    - Be careful about sending error reports for HTTPS requests

    We had to modify our error handler so that it does not dump the contents of POST, GET fields etc, in HTTPS requests, because doing so would involve them being stored and sent via (unencrypted) email. This is a violation of the user's security (even though it only happens in the case of an error) - in fact in one case a CC number was sent in this fashion (whoops!)

    So now it only tells us which fields are present/absent for HTTPS requests (For HTTP requests, it still sends everything).

    Slarty

  3. #3
    Senior Member
    Join Date
    Jan 2002
    Posts
    682
    Excellent point on the mail issue.

    There's actually various options you can set with cferror and exception handling with cfmx. This was the most basic and actually doesn't send full error details. (but as you correctly noted...you need to be aware of what could possibly be sent)

    I don't actually use the mail tag (Despite what I said in the article), I use another function which writes to the db which gives me a "todo list".
    I used to be With IT. But then they changed what IT was. Now what I'm with isn't IT, and what's IT seems scary and weird." - Abe Simpson

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •