IIS Request Filtering: Block SQL Injection

Organizations' database is an important asset, making it very attractive for attackers to target. SQL Injection is one of the most well-known, and painful attack vectors used against organizations' databases.

In most cases, IIS misconfiguration is the reason why organizations are vulnerable to this attack. A website is usually compromised because user data in web forms were not properly validated. Fortunately, regardless of a site's programming quality, it can still be protected. In this post, we will present IIS Request Filtering feature. We’ll share tips for writing efficient rules and Request Filtering recommended configuration.

CalCom offers a complete solution for IIS hardening- CSS for IIS. CSS for IIS will implement your desired policy directly on your production IIS servers. CSS for IIS will automatically produce an impact analysis report and will reveal the expected impact policy on your IIS servers to save you the need to test the policy and prevent painful server outages.

This blog post will cover:

1. An intro to SQL Injection attacks
2. How to detect SQL Injection attack
3. How to mitigate SQL Injection attacks
4. Request filtering rules tips
5. IIS Request Filtering according to best practices

A short intro to SQL Injection attacks:

SQL Injection is a code injection technique used to attack applications. It can be used in a range of ways to cause serious problems. Attackers can use tools, scripts, and even browsers to insert SQL statements into application fields. The statements are then executed by the database engine. Such attacks are usually used to:

1. Spoof identity

2. Tamper with existing data

3. Steal data

4. Destroy data

5. Change database permissions

6. Execute commands on the operating system.

The data behind an application is usually mission-critical, which is why SQL Injection attacks are considered very severe.

SQL Injection can be classified into three major categories - In-band SQLi, Inferential SQLi, and Out-of-band SQLi.

SQL server attacks: mechanisms you must know

Detecting SQL Injection:

When an SQL server is performing poorly, you might want to investigate if you were exposed to SQL Injection. Querying the logs for your website can start verifying your assumption. Here's an example of a Log Parser query to help you determine whether the was an SQL Injection attack:

logparser.exe -i:iisw3c "SELECT Top 25 Count(*) as HitCount, c-ip FROM C:\wwwlogs\w3svcXX\u_ex130806.log where cs-uri-query like '%cast%' GROUP BY c-ip ORDER BY HitCount Desc" -o:csv

* the string 'cast(' is one of the most common terms used in these cases.

Another clue can be found in your traffic logs. Checking the HTTP status code at the end of each request can identify malicious requests hiding between the legitimate requests. If the status code is 404 or 500, you'll know the malicious request didn't work. However, if the request's code is 200, you can start worrying.

After confirming that you were attacked, you should get back to the Log Parser query and get the IP addresses being used by the attacker. Add them to the IP Address and Domain Restrictions. This will also allow you to continue monitoring the site log files while you continue in your research. The requests coming from those IP addresses will have a status code of 403. You can also create a new Firewall rule to block those IP addresses.

Mitigating SQL Injection attacks:

The best way to mitigate SQL Injection attacks is to make sure your IIS server is not vulnerable to them to begin with. You can do it by filtering out potentially dangerous requests. IIS 7 and above presents a Request Filtering module that will allow you to filter out the dangerous requests.

A request filtering rule can block requests based on parameters such as file extensions, URLs, HTTP Verbs, Headers and Query Strings, query string maximal size and URL length. For example, you can use a Request Filtering rule to filter out queries containing the string 'cast(', often used in malicious queries.

When using a Query String rule, it'll scan the query string for .asp and .aspx pages denying anything that matches the string specified. Make sure you implement these rules carefully, as it can result in blocking legitimate traffic.

Setting the rules is done by editing the web.config file. The values are stored in the <requestFiltering> section under <system.webServer>:

5 Request Filtering Rules tips:

1. Deny String and scanned URL overlap- pay attention that if you use both the URL scanning and the Deny String feature, you might block undesired URLs if they contain the string you wish to deny.

2. Use Deny String for 'cast(' - while this string is used by almost any SQL Injection request, it is highly unlikely that it'll be used in a URL.

3. Use one string per rule- when writing Deny String rules it is highly recommended to separate each string to a different rule. This will ease the management and maintenance of the rules. In addition, in a case over overlap between a string and a URL, it'll be easier to locate the string and solve the problem.

4. Track blocked requests- request blocked by Request Filtering will return a 404-error status. Different blocking reasons have different sub status (see below). This is a Log Parser query to create a report containing all 404 errors with sub status greater than 0 (blocked by Filtering Rule sub status is 19):

logparser.exe "SELECT EXTRACT_FILENAME(cs-uri-stem) AS FILENAME, cs-uri-query, COUNT(*) AS TotalHits

FROM C:\wwwlogs\W3SVC35\u_ex141219.log TO results.txt

WHERE (sc-status = 404 AND sc-substatus > 0)

GROUP BY cs-uri-stem, cs-uri-query

ORDER BY TotalHits DESC

5. Blocking requests based on User-Agent- by investigating your logs you can identify specific User-Agent used for malicious activities. In this case, you can block this tool's requests by adding it's name to a Deny String rule.

IIS hardening: 6 configurations changes to harden IIS 10 web server

IIS Request Filtering configurations according to best practices:

1. Ensure 'maxAllowedContentLength' is configured – default value: 30000000 (approximately 28.6MB), recommended value: based on requirements to upload media.

2. Ensure 'maxURL request filter' is configured – default value (bytes): 4096, recommended value (bytes): 2048, sub status in IIS logs: 404.14

3. Ensure 'MaxQueryString request filter' is configured –default value (bytes): 2048, recommended value (bytes): 1024, sub status in IIS logs: 404.15

4. Ensure 'denyUrlSequences' is configured (non-ASCII characters in URLs are not allowed) – sub status in IIS logs: 404.5

5. Ensure 'denyQueryStringSequences request filter' is configured- sub status in IIS logs: 404.18

6. Ensure Double-Encoded requests will be rejected

7. Ensure 'HTTP Trace Method' is disabled

8. Ensure Unlisted File Extensions are not allowed

9. Ensure Handler is not granted Write and Script/Execute

10. Ensure 'notListedIsapisAllowed' is set to false

11. Ensure 'notListedCgisAllowed' is set to false

12. Ensure 'Dynamic IP Address Restrictions' is enabled

For the full IIS Hardening Guide, Click Here.