SQL Injection Technology and cross-site scripting attack detection

Author: K. K. Mo...

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, pay attention to the special meta-characters such as single quotation marks () and double extension signs (--) for a regular expression that detects SQL injection attacks (--), 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 modifier 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) | (=) [^] * (\ % 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. Generally, 1or1 = 1 string is used to discuss this attack. however, the detection of this string is easy to escape, such as using 1or2> 1 --. however, the only constant part is the initial character value, 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.

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.

UnionSQL 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, delete, and so on.

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

/(\ % 27) | () union/ix

(\ % 27) | ()-single quotes are 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.

If, at this stage, the attacker has discovered the SQL injection vulnerability in the web application and will try to exploit it. 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) pw +/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) p-'SP 'or 'xp letters are used to identify or expand the storage process
W +-one or more characters or underscores to match the name of a process

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. The <script> tag is displayed 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 "

/(