By Keren Pollack, on March 5th, 2020

SQL server attacks are one of the most painful attacks organizations can suffer from. Organizations’ database is one of their softest spots, resulting in it being an attractive target of attackers. Neglecting your organization’s SQL server security is equivalent to having a bomb ticking in your organization’s IT infrastructure.


There are different ways to protect your SQL server, from firewalls to assuring secure configurations. This article will present two of the most popular attacks and database breaching methods: SQL injection and SQL Obfuscation.

How to Protect Your Microsoft Server

SQL injection:

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 SQLiInferential SQLi, and Out-of-band SQLi.


In-band SQLi (Classic SQLi)

In-band SQL Injection is the most common and easy-to-exploit of SQL Injection attacks. in this kind of attack, the attacker can use the same communication channel to both launch the attack and gather the results.


Inferential SQLi (Blind SQLi)

Inferential SQL Injection may take longer for an attacker to exploit; however, it is just as dangerous as any other form of SQL Injection. In an inferential SQLi attack, no data is actually transferred via the web application. The attacker would see the results like in the in-band attack (which is why such attacks are commonly referred to as “blind SQL Injection attacks”). Instead, the attacker is able to change the database structure by sending payloads, observing the web application’s response and the resulting behavior of the database server.


Out-of-band SQLi

Out-of-band SQL Injection attack depends on enabled features on the database server, thereby it is not very common. the attacker will choose this type of attack when he is unable to use the same channel to both launch the attack and gather the results. Out-of-band SQLi techniques would rely on the database server’s ability to make DNS or HTTP requests to deliver data to an attacker.


SQL Obfuscation:

Obfuscation is one of the main tools for bypassing pattern-based security mechanisms such as web application firewalls (WAF). By tricking the firewall into thinking our attacks are legitimate traffic, we can successfully initiate, for example, an SQL injection attack without being detected by the WAF.


There are several methods that can be used to obfuscate our injections:


fuzzing is the process of finding hackable bugs by randomly feeding different permutations of data into a target program until one of those permutations reveals a vulnerability. It is important for firewall developers to be fully aware of all the database specifications and oddities. While some of them are documented, others can only be found through fuzzing. One example of peculiarities discovered through the use of fuzzers are the permitted whitespace characters for each type of database. Each different RDBMS allows a variety of different whitespace characters instead of the usual 0x20. By switching the standard whitespace with other allowed whitespace characters, the attacker can make his injection unrecognizable to certain firewalls allowing him to effectively bypass them.

Hardening IIS server guide


Encodings are another tool to use when bypassing WAFs. The web application may see the data in one way, while the proxy, firewall or database might interpret the data differently. It is because of these discrepancies between layers that encodings may work to bypass the WAF.


URL encode- URL Encoding is used to transform “special” characters, so they can be sent over HTTP. Characters get transformed into their hexadecimal equivalent, prefixed by a percent sign.


Double URL encode- Applying URL encode two times on the characters.


Unicode encode- Unicode is an industry-standard for representing over 110,000 symbols and characters for a wide range of languages. This encoding generally works against IIS servers or applications built in ASP or .NET.


UTF-8 encode- UTF-8 is a form of encoding each one of the code points in the Unicode character set. The number of blocks required to represent a character varies from 1 to 4.


Nibble encode- a nibble corresponds to a single hexadecimal digit. Since every character from ASCII range 0-255 can be represented in 1 byte, we can URL encode the 4 most significant bits, the 4 least significant bits or both of them.


Invalid Percent encode- this method is specific to .NET/IIS applications. The percent sign is added in between nonvalid hex characters so that the IIS will strip them and make the data valid. Any firewall that is unaware of this IIS behavior, won’t change the percent sign. This will allow mangling the SQL syntax, making it undetectable to the firewall.


Invalid Hex encode- this method isn’t exactly an encoding method. It is a way of affecting how applications convert hexadecimal to decimal. This method creates invalid hex that has the same decimal value as valid hex.


SQL Security:

Your SQL doesn’t have to be the breaking point of your network. Basic SQL security starts with hardening it by configuring it in the most secure fashion. Not so complex when you ave a small infrastructure, but extremely difficult in organizations with tangled IT infrastructure. Changing server’s configurations might result in production outages. In order to avoid it, dependencies in the system must be understood. But even after testing outcomes of every change, mistakes might happen that will lead to damaging applications function. CHS solves this problem for you. With CHS you can implement your desired policy directly on your production. CHS will learn your system’s dependencies and will do the impact analysis for you. After implementing the policy, CHS  will ensure you avoid configuration drifts by informing you about any unauthorized change in the server.