Use Snort to cleverly detect SQL injection and cross-site scripting attacks

Script attacks are the most crazy attack methods on the network recently. Many servers are equipped with advanced hardware firewalls and multi-level security systems, unfortunately, there is still no way to defend against SQL injection and cross-site scripting attacks on port 80. We can only watch the data being changed by malicious intruders without any solution-arm your Snort, use it to detect such attacks!
We will use the open-source Intrusion Detection System IDS as an example to compile a regular expression based on rules to monitor such attacks. By the way, in Snort, the default rule settings include the keyword used to detect cross-site scripting. Will there be a conflict? Don't worry, we still have a solution to this kind of conflict. We can express them in hexadecimal form of ASCII code. For example, if the keyword <script> exists in both the Snort and script, we can replace it with % 3C % 73% 63% 72% 69% 70% 3E.
If you want to detect each possible SQL injection, you only need to check the appearance of any SQL metacharacters, such as single quotes (') and semicolons (;) and double minus sign (--). Similarly, a paranoid way to monitor cross-site scripting attacks is to view the angle brackets (<,>) marked in HTML ). However, the preceding method may cause a large number of false positives. To avoid mischecking, we must set the filter rules as accurate as possible. Even so, we still cannot guarantee that no mischecking will occur and we can only do our best.
In this article, we will introduce in detail how to use Snort to detect strings in Perl. If you are not familiar with Perl, read the regular expression section in Perl.
1. Regular Expressions for SQL Injection
When selecting a regular expression for SQL injection, you must remember that in addition to attacks from the Cookie domain, attackers can also use the Form Input box. Therefore, when you perform logic verification on the input, you should also consider each input information from the user, such as form field and Cookie information should be considered as the suspect object. Similarly, if you find that many alarms against single quotes and semicolons may also be caused by information in cookies of Web applications. Therefore, such special symbols must be evaluated for specific Web applications.
As mentioned above, a weak regular expression used to detect SQL injection attacks is to check the metacharacters ('; --) mentioned above (';--). To detect such metacharacters or their hexadecimal equivalent representation, we can use the following regular expression:
/(\ % 27) | (') | (--) | (\ % 23) | (#)/ix
Here, % 27 is the hexadecimal value of single quotes, and % 23 is the hexadecimal value. Single quotes and short bars are special characters in ms SQL Server and Oracle. If we use MySQL, we must also check the appearance. Here we need to describe "-" and do not need to check its hexadecimal value because it is not an HTML metacharacter and will not be encoded by the browser. Similarly, if an attacker attempts to manually modify "-" to its hexadecimal value % 2D, the SQL injection operation will fail. To take care of the comrades who are not familiar with Perl, I will briefly explain the above regular expression: // is the code in Perl used to cause pattern matching, the complete form is m //. Generally, when we use a double slash to cause pattern matching code, we can omit m without writing. The symbol "|" is the role of or, just as in the general meaning of or in other languages. Parentheses are written to make it easier for readers to understand. The second or later I indicates that the letters to be matched are not case sensitive. The x after the second slash (/) indicates that the white space in the ignore mode is ignored.
We can add the above expression to the Snort rule: 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 example, the uriconten keyword section uses ". pl", because in our test environment, our CGI script is written in Perl. This part of content depends on your specific application, such as ". php", ". asp", and ". jsp. The content of the Pcre keyword is the pattern in which the. pl file will be checked. You can be inspired by this regular expression to write more Snort rules.
SQL queries may also contain pure numbers in the Where statement, as shown in the following code:
Select value1, value2, num_value3 from database where num_value3 = some_user_supplied_number
In this example, attackers may execute an additional SQL query statement, like this:
3; insert values into some_other_table
The above Snort rule can be extended to filter the appearance of semicolons. However, semicolons may also appear in normal HTTP interactions. In order to reduce false positives, the above rules can be modified to match parts after the equal sign (=. When a user uses GET or POST as a request, the input domain appears as follows:
Username = some_user_supplied_value & password = some_user_supplied_value
Therefore, the detection of user SQL injection attempts can start from the equal sign (=) or its hexadecimal value. The modified regular expression for SQL metacharacters detection is as follows:
/(\ % 3D) | (=) [^] * (\ % 27) | (') | (--) | (\ % 3B) | (;)/ix
This rule first checks the equal sign (=) or its hexadecimal % 3D. Next, [^] * means to match zero or multiple non-line break characters. Among them, it is a line break in Perl, and ^ is an exclude character, that is, a non-line break, * It means to perform zero or multiple matches on the character before it. The following part is no different from the previous one.
A typical SQL injection attempt usually creates a query around single quotes to check whether the returned results are correct and whether the SQL injection vulnerability exists. Most examples use the string '1' or '1' = '1. However, it is not easy to detect such strings, because attackers can easily construct equivalent strings, such as 1' or2> 1 --. In this way, the only unchanged part leaves a constant and the subsequent string 'or. For such attacks, we can construct the following regular expressions for detection. Typical Regular Expressions for SQL injection attacks:
/W * (\ % 27) | (') (\ % 6F) | o | (\ % 4F) (\ % 72) | r | (\ % 52)/ix
W (note that w here is in lower case, and w in Perl for pattern matching is different from W meaning) refers to uppercase and lowercase letters or numbers, * is used to match one or more numbers or letters. (\ % 27) | 'is used to match single quotes or its hexadecimal value. (\ % 6F) | o | (\ % 4F) (\ % 72) | r | (\ % 52 ), % 6F and % 4F are the hexadecimal values of the letter o, and % 72 and % 52 are respectively the hexadecimal values of the letter r. Because I options are used, it is not necessary to write the uppercase and lowercase letters o and r. In this way, we have considered various forms of word or.
Similarly, in SQL injection, we often use the union keyword. We can set the rules below to check the regular expression for SQL injection of the UNION Keyword:
/(\ % 27) | (') union/ix
With the above foundation, this rule does not need to be explained much. For select, insert, update, delete, drop and other statements that are frequently encountered, we can use the rules to set them flexibly.
In SQL injection, in order for the SQL Server to return errors, and then obtain useful information through errors, such as 1 = (select name from student where sno = '000000 '). The value returned by this subquery statement is of the character type, and 1 is a number. In this case, an error is reported, which exposes the content of the name field. This leads to the fact that we must be able to monitor such common injections. We cannot limit this type of attacks from 1, because this may lead to a large number of false checks. Obviously, the solution is to monitor the select keyword, because the information submitted in the URL, normally, the select keyword is not included.
2.5 regular expressions for monitoring similar queries on 1 = (select name from student where sno = '000000:
/(\ % 27) | (') select/ix
In ms SQL Server, extended stored procedures such as xp_mongoshell, xp_regread, and xp_regwrite are often used. When calling such stored procedures, the exec keyword must be used. In addition, the stored procedures of the system usually start with sp or xp. Therefore, we can configure Regular Expressions for such SQL injection as follows. Regular Expressions used for detecting SQL Injection in ms SQL Server:
/Exec (s | +) + (s | x) pw +/ix
Exec is the keyword that calls the stored procedure. (S | +) represents space or its equivalent replacement of HTTP encoding. + Match the preceding and subsequent characters at least once. In this way, (s | +) + (s | x) it means that space and s match with one of x at least once. W + has already explained it before. I will not talk about it here.
In the above, we only monitor some of the most basic methods of SQL injection. However, anyone familiar with SQL Injection knows that there are still many methods used in SQL injection, and we cannot write them one by one here, please be considerate.

2. Regular Expressions for cross-site scripting attacks
Before launching a cross-site scripting attack, attackers usually perform a simple HTML test to test website vulnerabilities, this may involve tags in HTML, such as <B>, <I>, and <u>. Similarly, you can use a simple script, such as <script> alert ("OK") </script>. This may be because most of the discussions on CSS use such a simple script example to determine whether a website can carry out CSS attacks. We can use Snort to detect such attempts. Some advanced intruders may use the transformation method for testing, such as replacing the corresponding hexadecimal value, for example, <script> replace % 3C % 73% 63% 72% 69% 70% 3E.
The following regular expression can be used to detect such attacks. It will capture attempts using <B>, <u>, or <script>. This regular expression is case-insensitive. We must match the symbol of the angle bracket with its hexadecimal value. The hexadecimal value of the Left angle bracket <is % 3C, the hexadecimal value of angle brackets> is % 3E. Regular Expressions for simple CSS Attacks:
/(\ % 3C) | <) (\ % 2F) |/) * [a-z0-9 \ %] + (\ % 3E) |>)/ix
(\ % 3C) | <) Checks left angle brackets. (\ % 2F) |/) * matches the slash or hexadecimal value indicating the end Of the tag. [A-z0-9 \ %] + matches more than one lowercase letter or Arabic number. (\ % 3E) |>) matches the right angle bracket or its hexadecimal value. Then, write this into the Snort rule: 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 be achieved by using the technology. For this type of attacks, we can configure this configuration to make CSS attacks not easy to implement. For C