1. Overview
In the past two years, security experts should pay more attention to attacks at the network application layer. Because no matter how strong your firewall rules are or how diligent you are in patching them, if your web application developers don't follow secure code, attackers will enter your system through port 80. The two main attack techniques that are widely used are SQL injection [ref1] and CSS [ref2] attacks. SQL injection refers to the technique of inserting SQL meta-characters (special characters representing some data) and instructions through the Internet input area to manipulate the execution of back-end SQL queries. These attacks mainly target WEB servers of other organizations. CSS attacks ensure that malicious Javascript code runs on the victim's machine by inserting script tags into URLs and then convincing users who trust them to click on them. These attacks take advantage of 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 the JavaScript code.
This article discusses detection techniques for SQL injection and CSS attack vulnerabilities. There has been a lot of discussion on the Internet about these two types of WEB-based attacks, such as how to implement the attacks, their impact, and how to better prepare and design programs to prevent these attacks. However, there is not enough discussion on how to detect these attacks. We use the popular open source IDS Snort [ref 3] to formulate regular expressions based on rules for detecting these attacks. Incidentally, Snort's default rule settings include methods for detecting CSS, but these can easily be avoided. For example, most of them use hex encoding, such as %3C%73%63%72%69%70% 74%3E instead of <script> to avoid detection.
Depending on the organization's capabilities at the level of paranoia, we have written multiple rules to detect the same attack. If you wish to detect all possible SQL injection attacks, then you need to simply pay attention to any existing SQL meta-characters, such as single quotes, semicolons and double dashes. Another extreme way to detect CSS attacks is to simply watch out for angle brackets in HTML tags. But this will detect a lot of errors. To avoid this, the rules need to be modified to make their detection more precise, while still not avoiding errors.
Use the pcre (Perl Compatible Regular Expressions) [ref4] keyword in Snort rules, and each rule can be taken with or without other rule actions. These rules can also be used by public software such as grep (a document search tool) to review network server logs. However, you need to be wary that the WEB server will record the user's input in the diary only when the request is submitted as GET. If the request is submitted as POST, it will not be recorded in the diary.
2. Regular Expressions for SQL Injection
When you choose a regular expression for a SQL injection attack, it is important to remember that an attacker can perform SQL injection by submitting a form, or through the Cookie field. Your input detection logic should consider various types of input organized by the user (such as form or cookie information). And if you find a lot of warnings coming from a rule, keep an eye out for single quotes or semicolons, as these characters may be valid input in cookies created by your web application. Therefore, you need to evaluate each rule against your particular web application.
As mentioned earlier, a detailed regular expression to detect SQL injection attacks should pay attention to the special meta-characters of SQL, such as single quotes (') and double expansion signs (--), in order to find out these characters and their hex equivalents number, the following regular expressions apply:
2.1 Regular expressions for detecting SQL meta-characters
/(%27)|(')|(--)|(%23)|(#)/ix
explanation:
We first check the hex of the single quote equivalent, the single quote itself or the double expansion sign . These are MS SQL Server or Oracle characters, indicating that the following are comments, and all subsequent ones will be ignored. In addition, if you use MySQL, you need to pay attention to the occurrence of '#' and its hex equivalent. Note that we don't need to check the hex for the double dash equivalent, since this is not an HTML meta-character and will not be encoded by the browser. Also, if an attacker manages to manually modify the double dash to its hex value of %2D (using a proxy like Achilles [ref 5]), the SQL injection will fail.
The new Snort rule added to the above regular expression is 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 In the discussion, the value of the uricontent keyword is ".pl" because in our test environment, the CGI program is written in Perl. The value of the uricontent keyword depends on your particular application. This value may be ".php", or ".asp", or ".jsp", etc. From this point of view, we do not show the corresponding Snort rules, but we will give the regular expressions that create these rules. You can easily create many Snort rules through these regular expressions. In the previous regular expressions, we detected double dashes because there may be SQL injection points even if there are no single quotes [ref 6]. For example, a SQL query entry contains only numerical values, as follows:
select value1, value2, num_value3 from database
where num_value3=some_user_supplied_number
In this case, the attacker can execute additional SQL queries. The demonstration submits the following input:
3; insert values into some_other_table.
Finally, the pcre modifiers 'i' and 'x' are used to match case and ignore respectively. blank space. The above rules can also be additionally extended to check for the presence of semicolons. However, the semicolon may well be part of a normal HTTP response. In order to reduce this error, and to prevent any normal occurrence of single quotes and double expansion signs, the above rules should be modified to detect the presence of = signs first. User input will respond to a GET or POST request. Generally, input is submitted as follows:
username=some_user_supplied_value&password=some_user_supplied_value
Therefore, SQL injection attempts will cause the user's input to appear after the a = sign or its equivalent hex value.
2.2 Correct the regular expression for detecting SQL meta-characters
/((%3D)|(=))[^n]*((%27)|(')|(--)|( %3B)|(:))/i
Explanation:
This rule first pays attention to the = sign or its hex value (%3D), then considers zero or more any characters except newlines, and finally detects single quotes and double dashes. or semicolon.
A typical SQL injection will try to manipulate the original query around the use of single quotes in order to get a useful value. This attack is generally discussed using the 1'or'1'='1 string. However, detection of this string can easily be evaded, such as using 1'or2>1 --. However, the only constant part is the value of the initial character, Follow a single quote and add 'or'. The Boolean logic that follows may vary across a range of styles, from ordinary to very complex. These attacks can be detected quite accurately using the following regular expression. Chapter 2.3 explains.
2.3 Typical SQL injection attack regular expression
/w*((%27)|('))((%6F)|o|(%4F))((%72)|r| (%52))/ix
explanation:
w* - Zero or more characters or underscores.
(%27)|' - a single quote or its hex equivalent.
(%6 F)|o|(%4 F))((%72)|r|-(%52) - The case of 'or' and its hex equivalent.
union'SQL query in SQL injection attacks are also very common in various databases. If the previous regular expression only detects single quotes or other SQL meta characters, it will cause many errors. You should further modify the query to detect single quotes and keys. word 'union'. This can also be further expanded with other SQL keywords, like 'select', 'insert', 'update', 'delete', etc.
2.4 Detecting SQL injection, UNION query keyword regular expression
/ ((%27)|('))union/ix
(%27)|(') - single quote and its hex equivalent
union - The union keyword
can also be used to customize expressions for other SQL queries, such as >select, insert, update, delete, drop, etc.
If, by this stage, the attacker has discovered that the web application has a SQL injection vulnerability, he will Try to take advantage of it. If he realizes that the backend server is MS SQL server, he will usually try to run some dangerous storage and extended stored procedures. These procedures generally begin with the letters 'sp' or 'xp'. Typically, he might try to run the 'xp_cmdshell' extended stored procedure (which executes Windows commands through SQL Server). The SA authority of the SQL server has the authority to execute these commands. Similarly, they can modify the registry through xp_regread, xp_regwrite and other stored procedures.
2.5 Explanation of the regular expression
/exec(s|+)+(s|x)pw+/ix
for detecting MS SQL Server SQL injection attacks:
exec - keyword that requests execution of a stored or extended stored procedure
(s|+)+ - one or more whitespaces or their http equivalents
(s|x) p- 'sp' or 'xp' letters are used to identify storage or extended storage procedures
w+ - one or more characters or underscores to match the name of a procedure
3. Regular expression for cross-site scripting (CSS)
When launching a CSS attack or detecting a website vulnerability, an attacker may first make a simple HTML tag such as < b> (bold), <i> (italics) or <u> (underline), or he might try a simple script tag like <script>alert("OK")</script>. Because most publications and This is used as an example to detect whether a website has CSS vulnerabilities propagated through the Internet. These attempts can be easily detected. However, a clever attacker could replace the entire string with its hex value. In this way, the <script> tag will appear as %3C%73%63%72%69%70%74%3E. On the other hand, an attacker may use a web proxy server like Achilles to automatically convert some special characters such as < to %3C, > to %3E. When such an attack occurs, angle brackets are usually replaced with hex values in the URL.
The following regular expression will detect any text containing <, > in html. It will catch attempts to use <b>, <u>, or <script>. This regex should ignore case. We need to detect both the angle bracket and its hex equivalent (% 3C|<). To detect the entire string converted to hex, we must detect the numbers and % signs entered by the user, that is, use [a-z0-9%]. This may cause some bugs to appear, but not most will detect real attacks.
3.1 Regular expression for general CSS attacks
/((%3C)|<)((%2F)|/)*[a-z0-9%]+((%3E)|>)/ix
explain:
((%3C)|<) - checks < and its hex equivalent
((%2F)|/)* - closing tag/ or its hex equivalent
[a-z0-9%]+ - Check the letter in the tag or its hex equivalent
((%3E)|>) - Check for > or its hex equivalent
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 used< img src=>Technology. The current default snort rules can be easily circumvented.
Section 3.2 provides methods to prevent this technique.
3.2 "<img src" CSS attack regular expression
/((%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) -'img' letter or it Variation combinations of uppercase and lowercase hex equivalents
[^n]+ - any character following <img except newline
(%3E)|>) -> or its hex equivalent
3.3 CSS Attack Extreme Regular Expression
/((%3C)|<)[^n]+((%3E)|>) /I
Explanation:
This rule simply looks for <+any character except a newline character+>. Depending on the architecture of your web server and web application, this rule may produce some errors. But it is guaranteed to catch any CCS or CSS-like attacks.
Summary:
In this article, we proposed different kinds of regular expression rules to detect SQL injection and cross-site scripting attacks. Some rules are simple and extreme, and a potential attack will raise your alarm. But these extreme rules can lead to some proactive errors. With this in mind, we modified these simple rules to use additional styles so that they can be checked more accurately. In detecting attacks on these network applications, we recommend using these as a starting point for debugging your IDS or log analysis methods. After a few more revisions, you should be ready to detect those attacks after you've evaluated the non-malicious responses to the normal network transaction portion.
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