SQL injection technology and cross-site scripting attack detection (1) _ MySQL

SQL injection technology and cross-site scripting attack detection (1) 1. Overview

In the past two years, security experts should pay more attention to attacks at the network application layer. No matter how strong firewall rule settings you have or how often you fix vulnerabilities, if your network application developers do not follow the security code for development, attackers will access your system through port 80.

The two most widely used attack technologies are SQL injection [ref1] and CSS [ref2] attacks. SQL injection refers to the technology that inserts SQL meta-characters (special characters represent some data) and instructions to execute back-end SQL queries in the input area of the Internet. These attacks mainly target WEB servers of other organizations. CSS attacks insert script tags in URLs, and then induce users who trust them to click on them to ensure that malicious JavaScript code runs on the victim's machine. These attacks use the trust relationship between the user and the server. In fact, the server does not detect the input and output, and thus does not reject JavaScript code.

This article discusses SQL injection and CSS attack vulnerability detection technologies. There have been a lot of discussions on these two WEB-based attacks, such as how to launch attacks, their impact, and how to better compile and design programs to prevent these attacks. However, there is not enough discussion about how to detect these attacks. We use the popular open-source IDS Snort [ref 3] to construct a regular expression based on the rules used to detect these attacks. Additionally, Snort default rules are used to set methods that contain CSS detection, but these methods are easy to avoid detection. For example, most hex encoding methods, such as % 3C % 73% 63% 72% 69% 70% 3E, are used to replace script to avoid detection.

Depending on the capabilities of the level of paranoia organization, we have compiled multiple rules for detecting the same attack. If you want to detect various possible SQL injection attacks, you need to pay attention to any current SQL meta-characters, such as single quotes, semicolons, and double dashes. For the same method of detecting CSS attacks, simply guard against HTML-tagged angle brackets. However, this will detect many errors. In order to avoid this, these rules need to be modified to make it more accurate to detect, while still cannot avoid errors.

Use the pcre (Perl Compatible Regular Expressions) [ref4] keyword in Snort rules. each rule can contain or does not contain other rule actions. These rules can also be used by public software such as grep (document search tool) to review network server logs. However, it is important to note that the WEB server will only record the logs of user input when a request is submitted with GET. requests submitted with POST will not be recorded in the log.

2. Regular expression of SQL injection

When you select regular expression for SQL injection attacks, remember that the attacker can submit a form for SQL injection or use the Cookie area. Your input detection logic should consider various types of input (such as form or Cookie information) of the user organization ). And if you find that many warnings come from one rule, pay attention to single quotes or semicolons. maybe some characters are the valid input in CookieS created by your Web application. Therefore, you need to evaluate each rule based on your special WEB application.

As mentioned above, a fine-grained regular expression for detecting SQL injection attacks should pay attention to the special meta-characters of SQL, such as single quotation marks (') and double extension signs (--), the following regular expression applies to finding out the equivalence between these characters and their hex:

2.1 check the regular expression of SQL meta-characters
/(/% 27) | (/') | (/-) | (/% 23) | (#)/ix

Explanation:

We should first check the hex with single quotes, single quotes, or double quotation marks. These are characters of ms SQL Server or Oracle, which indicate that the comment is followed, and the comment will be ignored later. In addition, if you use MySQL, you need to pay attention to the appearance of '#' and its equivalent hex. Note that we do not need to check the hex equivalent to the double break number, because this is not an HTML meta-character and the browser will not encode it. In addition, if the attacker tries to manually modify the double break number to its hex value % 2D (using a proxy like Achilles [ref 5]), SQL injection will fail.
The new Snort rules added with the regular expression are as follows:

Alert tcp $ EXTERNAL_NET any-> $ HTTP_SERVERS $ HTTP_PORTS (msg: "SQL Injection-Paranoid"; flow: to_server, established; uricontent :". pl "; pcre:"/(/% 27) | (/') | (/-) | (% 23) | (#)/I "; classtype: web-application-attack; sid: 9099; rev: 5 ;)

In this article, the uricontent keyword value is ". pl", because in our test environment, CGI programs are written in Perl. The value of the uricontent keyword depends on your special application. The value may be ". PHP", ". ASP", or ". JSP. In this case, we do not display the corresponding Snort rules, but we will provide a regular expression for creating these rules. Using these regular expressions, you can easily create many Snort rules. in the previous regular expression, we checked the double break because: even if there is no single quotation mark, it may be the SQL injection point [ref 6]. For example, an SQL query entry contains only numeric values, as shown below:

Select value1, value2, num_value3 from database
Where num_value3 = some_user_supplied_number

In this case, attackers can execute additional SQL queries. The example submits the following input:

3; insert values into some_other_table

Finally, the modifiers 'I' and 'X' of pcre are used to match the case and ignore the blank spaces respectively. The above rules can also be extended to check the existence of semicolons. However, a semicolon can be part of a normal HTTP response. In order to reduce this error, it is also for the emergence of any normal single quotes and double extension numbers. the above rule should be modified to first detect the deposit of =. User input will respond to a GET or POST request. Generally, the input is submitted as follows:

Username = some_user_supplied_value & password = some_user_supplied_value

Therefore, SQL injection attempts will cause user input to appear after a = sign or its equivalent hex value.

2.2 modify the regular expression used to check SQL meta-characters

/(/% 3D) | (=) [^/n] * (/% 27) | (/') | (/-/-) | (/% 3B) | (:)/I

Explanation:

This rule first pays attention to the = or its hex value (% 3D), then considers zero or multiple arbitrary characters except line breaks, and finally checks single quotes, double breaks or semicolons.

Typical SQL injection attempts to operate the original query around the use of single quotes to obtain useful value. To discuss this attack, we usually use 1 'or '1' = '1 string. however, the investigation of this string is easy to escape, for example, using 1 'or2> 1 --. however, the only constant part is the value of the original character, followed by a single quotation mark, plus 'or '. The subsequent Boolean logic may change within a certain range, which may be a common style or very complicated. These attacks can be detected with exact precision through the following regular expressions. 2.3 Chapter