How to detect SQL injection technology and cross-site scripting attacks

In the last two years, security experts should be more focused on attacks on the network application layer. Because no matter how strong your firewall rule setting or the most diligent patching mechanism is, if your Web application developer does not follow the security code for development, the attacker will enter your system via 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 sqlmeta-characters (special characters representing some data) and instructions through the input area of the Internet, manipulating the execution of the backend SQL queries. These attacks are primarily targeted at other organizations ' Web servers. CSS attacks make sure that malicious JavaScript code runs on the victim's machine by inserting a script tag in the URL and then inducing the user who trusts them to click on them. These attacks take advantage of the trust relationship between the user and the server, and in fact the server does not detect input or output and thus does not reject JavaScript code.

This article discusses the detection techniques for SQL injection and CSS attack vulnerabilities. There have been a lot of discussions about these two web-based attacks on the web, such as how to implement 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 popular open source IDSSNORT[REF3 to build regular expressions based on the rules that detect these attacks. Incidentally, the Snort default rule setting contains methods for detecting CSS, but these are easily bypassed for detection. For example, mostly through hex coding, such as%3c%73%63%72%69%70%74%3e instead of avoiding detection.

Depending on the capabilities of the Levelofparanoia organization, we have written a variety of rules for detecting the same attack. If you want to detect various possible SQL injection attacks, then you need to simply pay attention to any existing sqlmeta-characters, such as single quotes, semicolons, and double dashes. The same extreme method of detecting CSS attacks is simply to beware of the corner brackets of HTML tags. But this will detect a lot of errors. To avoid these, these rules need to be modified to make it more accurate to detect, while still avoiding errors.

The Pcre (perlcompatibleregularexpressions) [REF4] keyword is used in snort rules, and each rule can take or take no other rule action. These rules can also be used by public software such as grep (document Search tool) to review network server logs. However, it is necessary to be vigilant that the Web server records the journal only when a request is submitted with a get, and if the request submitted by post is not recorded in the journal.

Regular expressions for 2.SQL injection

When you select a regular expression for a SQL injection attack, it is important to remember that an attacker can either submit a form for SQL injection or pass through a cookie area. Your input detection logic should consider various types of input from the user's organization (such as forms or cookie information). And if you find that many warnings come from a rule, please pay attention to single quotes or semicolons, and perhaps some characters are created by your Web application that are legitimate input into cookies. Therefore, you need to evaluate each rule based on your particular Web application.

As mentioned earlier, a trivial regular expression to detect SQL injection attacks should pay attention to SQL special meta-characters such as single quotation mark (') Double extension number (--), in order to detect these characters and their hex equivalent number, the following regular expression applies:

2.1 Regular Expressions for detecting sqlmeta-characters

/(%27) | (') | (--)| (%23) | (#)/ix

Explain:

We first check the single quotation mark equivalent of the hex, the single quotation mark itself or the double fold extension number. These are MSSQLSERVER or Oracle characters that represent the comments that follow and will be ignored. In addition, if you use MySQL, you need to pay attention to ' # ' and its equivalent of the hex appearance. Note that we do not need to check the hex of the double dash equivalent, because this is not a htmlmeta-character and the browser will not encode it. Also, if the attacker tries to manually modify the double dash for its hex value%2d (using the proxy like ACHILLES[REF5]), SQL injection will fail.

The new snort rules that add the above regular expressions are as follows:

alerttcp$external_netany-> $HTTP _servers$http_ports (msg: "sqlinjection-paranoid"; flow:to_server,established; Uricontent: ". pl";p cre: "/(%27) | (') | (--)| (%23) | (#)/I "; classtype:web-application-attack;sid:9099;rev:5;

In this 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, which may be ". php", or ". asp", or ". JSP", and so on. From this point of view, we do not display the corresponding snort rules, but we will give a regular expression that creates these rules. With these regular expressions you can simply create a lot of snort rules. In the previous regular expression, we detect the double dash because: even if there is no single quotation mark there may be a SQL injection point [REF6]. For example, an SQL query entry contains only numeric values, as follows:

Selectvalue1,value2,num_value3fromdatabase

Wherenum_value3=some_user_supplied_number

In this case, an attacker could execute an additional SQL query, demonstrating the following input:

3;insertvaluesintosome_other_table

Finally, the modifier ' I ' and ' X ' of the pcre are used to match the case and ignore the blanks respectively. The above rules can also be extended to check the existence of semicolons. However, semicolons can be part of a normal HTTP response. In order to reduce this error, it is also for any normal single quotes and double extension numbers out of

Now, the above rules should be modified to first detect the deposit of = number. User input responds to a GET or POST request, and the general input is submitted as follows:

Username=some_user_supplied_value&password=some_user_supplied_value

Therefore, the SQL injection attempt will cause the user's input to appear after the a= number or its equivalent hex value.

2.2 Correction detection sqlmeta-characters Regular expression

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