Detection of SQL injection and cross-site scripting attacks

Detection of SQL injection and cross-site scripting attacks

Created:
Article attributes: Translation
Article submission: h4k_b4n (h4k. b4n_at_gmail.com)

Author: K. K. mookhey, Nilesh burghate,
Translation organization: [bug. Center. Team-vulnerability Warning Center team]
Translation: fpx [B .C. T]

1. Introduction
In the last 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 of them are hex encoded, such as % 3C % 73% 63% 72% 69% 70% 3E instead of <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 first check the hex equivalent to single quotes, single quotes, or double extension signs. 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 any normal single quotes and double expansion

Now, the above rule should be modified to first check =. 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 the following regular expressions. 2.3.

2.3 Regular Expressions for typical SQL injection attacks

// W * (/% 27) | (/') (/% 6f) | o | (/% 4f) (/% 72) | r | (/% 52)/IX

Explanation:
/W *-zero or multiple characters or underscores.
(/% 27) |/'-single quotes or its hex equivalent.
(/% 6 F) | o | (/% 4 f) (/% 72) | r |-(/% 52) -The Case of 'or' and its hex equivalent.

'Join' SQL queries are also common in SQL injection attacks against various databases. If the preceding regular expression only detects single quotes or other SQL meta characters, many errors may occur. You should further modify the query to check single quotes and the keyword 'join '. This can also further expand other SQL keywords, such as 'select', 'insert', 'update', and 'delete.

2.4 check regular expressions for SQL injection and Union query keywords.

/(/% 27) | (/') Union/IX

(/% 27) | (/')-the single quotation mark is equivalent to its hex
Union-Union keyword

You can also customize expressions for other SQL queries, such as> select, insert, update, delete, drop, and so on.

At this stage, the attacker will try to exploit the SQL injection vulnerability in the Web application. If he realizes that the backend server is ms SQL Server, he generally tries to run some dangerous storage and extended storage processes. These processes generally start with a letter 'SP 'or 'xp. Typically, he may try to run 'xp _ external shell' to expand the storage process (run Windows commands through SQL Server ). The SA permission of the SQL Server has the permission to execute these commands. They can also modify the Registry through stored procedures such as xp_regread and xp_regwrite.

2.5 regular expression for detecting ms SQL Server SQL injection attacks

/Exec (/S |/+) + (S | x) p/W +/IX

Explanation:
Exec-keywords for request execution of storage or extended storage process
(/S |/+) +-one or more white spaces or their HTTP equivalent Codes
(S | x) the p-'SP 'or 'xp' letter is used to identify the stored or extended storage process
/W +-one or more characters or underscores to match the process name

3. Regular Expressions for cross-site scripting (CSS)

When launching a CSS attack or detecting a website vulnerability, attackers may first make simple HTML tags such as <B> (BOLD), <I> (italic) or <u> (underline), or he may try a simple script tag, such as <SCRIPT> alert ("OK") </SCRIPT>. this is an example for most publications and websites that detect CSS vulnerabilities. These attempts can be easily detected. However, a clever attacker may use its HEX value to replace the entire string. In this way, the <SCRIPT> tag will appear as % 3C % 73% 63% 72% 69% 70% 3E. On the other hand, attackers may use web proxy servers like Achilles to automatically convert some special characters such as <changed to % 3C,> to % 3E. when such an attack occurs, the URL usually replaces the angle brackets with the hex equivalent.

The following regular expressions detect HTML contained in any text <,>. It will catch the attempt to use <B>, <u>, or <SCRIPT>. This regular expression should be case-insensitive. We need to detect the hex equivalent of the angle brackets (% 3C | <) at the same time ). To detect the entire hex hexadecimal conversion string, we must check the number and % Number entered by the user, that is, using [a-z0-9 %]. This may cause some errors, not most of which detect actual attacks.

3.1 Regular Expressions for general CSS attacks

/(/% 3C) | <) (/% 2f) | //) * [a-z0-9/%] + (/% 3e) |>)/IX

Explanation:
(/% 3C) | <)-check <equivalent to its hex
(/% 2f) | //) *-end tag/or its hex equivalent
[A-z0-9/%] +-check the letter in the tag or its hex equivalent
(/% 3e) |>)-check> or its hex equivalent

Snort rules:
Alert TCP $ external_net any-> $ http_servers $ http_ports (MSG: "NII cross-site scripting attempt"; flow: to_server, established; PCRE: "/(/% 3C) | <) (/% 2f) | //) * [a-z0-9/%] + (/% 3e) |>)/I "; classtype: web-Application-attack; Sid: 9000; Rev: 5 ;)

Cross-site Scripting can also use the technology. The default snort rules can be easily avoided.

Chapter 3.2 provides methods to prevent such technology.

3.2 "

/(/% 3C) | <) (/% 69) | I | (/% 49) (/% 6d) | M | (/% 4d )) (/% 67) | G | (/% 47) [^/n] + (/% 3e) |>)/I

Explanation:
(/% 3 C) | <)-<or its hex equivalent
(/% 69) | I | (/% 49) (/% 6d) | M | (/% 4d) (/% 67) | G | (/% 47)-variable combination of the 'img 'letter or its case-sensitive hex equivalent
[^/N] +-any character that follows (/% 3e) |>)-> or its hex equivalent

3.3 extreme regular expressions of CSS attacks

/(/% 3C) | <) [^/n] + (/% 3e) |>)/I

Explanation:
This rule is simple to find <+ any character except the line break +>. Due to the architecture of your Web server and web application, this rule may produce some errors. But it can catch any ccs or CSS-like attacks.

For a good CSS method that avoids filtering, refer to BugTraq's contribution.
Http://www.securityfocus.com/archive/1/272...rchive/1/272037.
However, note that the last extreme rule can detect all these attacks.

Summary:

In this article, we propose different types of regular expression rules to detect SQL injection and cross-site scripting attacks. Some rules are simple and extreme, and a potential attack will be vigilant. However, these extreme rules may lead to some active errors. With this in mind, we have modified these simple rules and used other styles to make them more accurate. In the attack detection of these network applications, we recommend that you use these as the starting point for debugging your IDs or log analysis methods. After several modifications, you should be able to detect the attacks after evaluating the non-malicious responses to normal online transactions.

Reference
1. SQL Injection

Http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
2. Cross Site Scripting FAQ http://www.cgisecurity.com/articles/xss-

Faq.shtml
3. The Snort IDS http://www.snort.org
4. Perl-Compatible Regular Expressions (PCRE) http://www.pcre.org
5. Web application proxy, Achilles http://achilles.mavensecurity.com
3. Advanced SQL Injection

Http://www.nextgenss.com/papers/advanced_ SQL _injection.pdf
7. Secure Programming howto, David Wheeler www.dwheeler.com
8. Threats and Countermeasures, msdn, Microsoft

Http://msdn.microsoft.com