How IAG 2007 Can Mitigate Against SQL Injection Attacks – Demo Scenario

edgeaccessblog — Fri, 19 Sep 2008 21:34:00 GMT

1. Introduction

SQL Injection is a potential threat to any web application that has an SQL based database backend. This is true not just for Microsoft SQL backend but any web application on any OS with an SQL database backend. There are lots of applications and application developers that didn’t or still don’t follow guidelines designed to mitigate or avoid this type of vulnerability. The questions that keep coming to the Forefront Edge Security Team about this is: can we mitigate this threat anyway at the edge before the injection reaches the SQL database? IAG 2007 can help you on that. With IAG 2007 administrations can specify the allowed parameters and return values from each field in the application that interacts with SQL and therefore mitigate possible SQL Injection attacks.

It is very important to realize that ideally this mitigation should be done in the source code of the web application, rather than by using a device on the edge, as this is more of a bandage than a fix. This is because the application will still be vulnerable to attacks originating from the internal network and not passing the edge, as well as also not being protected against the possibility of administrators having missed some mitigation on the edge device which could have been done better in the application code. The bottom line is don’t use the edge as your ultimate protection mechanism for this type of attack.

Before we move on to the sample implementation, it is recommended that you review the following articles that provide details about SQL Injections and the ways to mitigate the problem in applications:

MSRC’s advisory, includes links to tools for developers and IT professionals

http://www.microsoft.com/technet/security/advisory/954462.mspx

Covers the ins-and-outs of the mass SQL attacks

http://blogs.technet.com/swi/archive/2008/05/29/sql-injection-attack.aspx

Covers how to use parameterized queries in classic ASP

http://msdn.microsoft.com/en-us/library/cc676512.aspx

Additional examples of parameterized queries

http://blogs.technet.com/neilcar/archive/2008/05/21/sql-injection-mitigation-using-parameterized-queries.aspx

http://blogs.technet.com/neilcar/archive/2008/05/23/sql-injection-mitigation-using-parameterized-queries-part-2-types-and-recordsets.aspx

2. Weak Application Code – Sample

For this example we are going to use Nazim’s (from IIS Team) SQL Injection Demo code that he wrote for his blog. Nazim provides a very interesting example of how you can easily create weak code and what can happen when you do this.

3. Configuring IAG to publish the Web Application and inspect the traffic

The first step is to publish the web application:

· Follow Nazim’s blog to create the database and the asp code

· Create a website in IIS (it works perfectly with IIS 6)

· Add the two pages to the new website and put the web server behind IAG.

· Create a portal trunk in IAG

· Add a Generic Web Application to the newly created portal trunk

· Set the Application Type to SQL

· Follow the wizard to point the application to the web server & site you created with Nazim’s code

· Configure the Portal Link to have something like the following URL:

Figure 1 – Portal Link URL for this example.

After completing the configuration of the Web Application in IAG, follow the steps below to configure the URL Set that will block the SQL Injection attempts:

1. Select the Portal Trunk that you created the web application on.

2. Click the configuration button next to Advanced Trunk Configuration.

3. Click on the URL Set tab.

4. Look for the rule name that starts with the Application Type of your application. Look for this rule in the Name field (for this example the application type is SQL ) and click on it.

5. Change the Parameters column from Ignore to Handle

6. Make sure that the methods are set to be POST and GET.

7. Change the Parameter List according to the Figure 2:

Figure 2 – URL Set configuration.

Here is the real deal of this implementation: you need to know the application that you are publishing and know exactly what the parameters are, in order to make this configuration. By parameters, we refer to both query string parameters as well as to POST-ed form fields sent from the client as HTTP data. IAG collects both of these and then analyses them, one by one, against the specific rules configured. For this example the following fields were used:

Name

Name Type

Value

Length

Existence

Name of the parameter. This can be specified as the real parameter, as it appears in HTTP requests, or as a regular expression

The type of the parameter’s Name field.

· String: The parameter name is the real parameter, as it appears in HTTP requests

· Regular expression: this can be used in order to create one single definition that matches multiple parameters

The valid characters that can this parameter’s value can hold. Here you will type values using Regular Expression that can cover the valid strings that this field should accept. You have the option to leave this field empty, in which case the Value requirement is not enforced by IAG, but still other requirements, like Length and Existence, are enforced.

Length of this parameter. This field accepts a range. For example:

· 4:10: means four to ten chars in length are allowed

· 4:4: means only exactly four chars in length are allowed

Possible values:

· Mandatory: parameter must exist in the request

· Optional: parameter may or may not exist

· Reject: HTTP request will be rejected if this parameter appears in it

1. After making the above changes, click OK.

2. Click Activate to apply the changes.

Now that IAG is configured and ready, it’s time to test the examples from Nazim’s SQL Injection Demo blog post.

First example will be:

· Test 1 - Bypassing login for a known user. Let's say we know user 'Yuri' exists and using the '--' for commenting out the rest of the conditions in the query:

o Username: Yuri'--

o Password: nothing

IAG will intercept the traffic and it will display an error.

Figure 3 – Error that the user receives when clicking on Submit.

Going to IAG 2007 Web Monitor we have the following event:

Figure 4 – Parameter that was flagged as invalid.

If we try example 4 from Nazim’s SQL Injection Demo blog post we will have:

· Test 4 - Injecting a new user. Let's say I want to add a user 'Hijack' with password 'This'.:

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

o Password: nothing

When user tries to do that the following warning will appear in the IAG Web Monitor and the user will receive the same error as in Figure 5.

Figure 5 – Another attempt to exploit the application by inserting a new user.

4. Conclusion

This post gives you an overview on how IAG can be used to help mitigate SQL Injection attacks coming from external users against applications that are published through an IAG Portal. As explained above, while this is a good step, this is not the definitive answer for fixing SQL Injection problems in your environment. This does go a long way in preventing a problem, but the root cause is unchanged and until it’s resolved and the application is written securely, the potential for problems will continue to exist.

Author

Yuri Diogenes

Security Support Engineer – ISA/IAG Team

Microsoft – Texas

Technical Reviewer
Dan Herzog

Security Support Engineer – IAG Team

Microsoft – Washington

Ran Dolev
Security Consultant – IAG Team
Microsoft – Israel

Microsoft Forefront Unified Access Gateway Product Team Blog : SQL Injection

How IAG 2007 Can Mitigate Against SQL Injection Attacks – Demo Scenario