Web Application Firewall (WAF) protects the security and stability of Web services by detecting HTTP(S) requests, identifying and blocking SQL injection, cross-site scripting attacks, cross-site request forgery and other attacks.
Web security is a must-have feature for all Internet applications. Applications without security protection are like a child carrying jewelry walking alone in the dark night surrounded by thieves. We are going to develop a Web application firewall, which can be used as a Web plug-in and deployed at the entrance of HTTP services such as Web applications or microservice gateways to intercept malicious requests and protect system security. The name of the Web application firewall we are going to develop is "SkyNet".
demand analysis
When an HTTP request is sent to the Web server, the request first reaches the SkyNet firewall, and the firewall determines whether the request contains malicious attack information. If included, the firewall can choose to reject the request and return a 418 status code according to the configuration policy; it can also disinfect the malicious data in the request, that is, replace the malicious data or insert certain characters so that the request data no longer Be aggressive before calling application processing. As shown below:
List of attacks and security vulnerabilities SkyNet needs to address:
Outline design
The main means by which SkyNet can discover malicious attack requests is to perform regular expression matching on the HTTP request content, construct the malicious content that may be contained in various attack types into regular expressions, and then match the HTTP request header and request body. If the match is successful, the relevant processing logic will be triggered to directly reject the request; or the malicious content in the request will be disinfected, that is, character replacement will be performed to prevent the attack from taking effect.
Among them, the malicious content regular expression is obtained through remote configuration. If a new attack vulnerability is discovered, the remotely configured vulnerability attack regular expression will be updated and take effect on all servers running SkyNet firewall to block new attacks. The component diagram is as follows:
The HTTP request reaches the request filter first, and the request filter extracts the data in the HTTP request header and HTTP request body. This filter is actually the Filter in Java. The filter calls the vulnerability policy processor for processing, and the vulnerability policy processor needs to call the vulnerability definition file loading module to obtain the vulnerability definition rules. The vulnerability definition file loading module caches various vulnerability definition rule files. If the cache times out, it will be retrieved from the remote configuration center. Reload vulnerability definition rules.
The vulnerability definition rule file is the core of SkyNet. This file defines the regular expression of the attack. The filter uses these regular expressions to match the HTTP request header and the HTTP request body to identify whether there is attack content in the HTTP request. At the same time, the vulnerability definition rule file also defines the processing method after discovering the attack content: whether to reject the request, jump to the error page, or use disinfection to replace the attack content characters.
The vulnerability rule definition file is in XML format. The example is as follows:
<?xml version="1.0"?>
<recipe
attacktype="Sql"
path="^/protectfolder/.*$"
description="Sql injection attacks"
>
<ruleSet
stage = "request"
condition = "or"
>
<action
name="forward"
arg="error.html"
/>
<rule
operator = "regex"
arg = "paramNames[*]"
value = "select|update|delete|count|*|sum|master|script|'|declare|
or|execute|alter|statement|executeQuery|count|executeUpdate"
/>
</ruleSet>
<ruleSet
stage = "response"
condition = "or"
>
<action
name ="replace"
arg = " "
/>
<rule
operator = "regex"
arg = " responseBody "
value = "(//.+\n)|(/\*\*.+\*/)|(<!--.*-->)"
/>
</ruleSet>
</recipe>recipe is the root tag of the vulnerability definition file, and the attribute attacktype indicates the type of attack to be processed, which are as follows.
SQL: SQL injection attack
XSS: Cross-site scripting attack
CSC: Comments and exception information leakage
CSRF: Cross-site request forgery
FB: Path traversal and forced browsing
path represents the request path to be processed, which can be empty, indicating that all request paths will be processed.
ruleSet is a set of vulnerability processing rules, and a vulnerability file can contain multiple ruleSets. The stage tag indicates the stage of processing, request stage: request, response stage: response. condition represents the logical relationship with other rules, "or" represents the "or" relationship, that is, after the rule is processed, other rules do not need to be processed; "and" represents the "and" relationship, after the rule is processed, other rules still need to be processed. Needs further processing.
action represents the processing action after the attack is discovered. "forward" means to jump to the error page, and the following "arg" indicates the path to be jumped; "replace" means to replace the attack content, which is the so-called disinfection, so that it is no longer offensive. The following "arg" ” indicates the content to be replaced.
rule represents a vulnerability rule. Triggering a vulnerability rule will cause action processing. The operator indicates how to match the attack content in the content, "regex" indicates regular expression matching, and "urlmatch" indicates URL path matching. "arg" represents the target to be matched, which can be HTTP request parameter name, request parameter value, request header, response body, or ULR path. "value" is the regular expression that matches the attack content.
detailed design
What types of attacks can SkyNet handle? What is their principle? What is the corresponding processing method for SkyNet? Detailed design will address these issues.
XSS cross-site scripting attack
XSS attack, also known as Cross Site Script, refers to an attack method in which hackers tamper with web pages, inject malicious JavaScript scripts, and control the user's browser to perform malicious operations when users browse web pages.
There are two common types of XSS attacks. One is the reflection type, where the attacker induces the user to click on a link embedded with a malicious script to achieve the purpose of the attack. As shown in the picture:
There is a URL containing a malicious script in the Weibo posted by the attacker (in actual application, the script is on the attacker's own server www.2kt.cn, and the URL contains a link to the script). When the user clicks on the URL, it will automatically Pay attention to the attacker's Sina Weibo ID, publish a Weibo containing a malicious script URL, and the attack will be spread.
Another type of XSS attack is a persistent XSS attack. The hacker submits a request containing a malicious script and saves it in the database of the attacked website. When the user browses the web page, the malicious script is included in the normal page to achieve the purpose of the attack. As shown in the picture:
This type of attack is often used in web applications such as forums and blogs.
SkyNet uses regular expressions to match requests containing XSS attack content. The regular expressions are as follows:
"(?:\b(?:on(?:(?:mo(?:use(?:o(?:ver|ut)|down|move|up)|ve)|key(?:press|down|up)|c(?:hange|lick)|s(?:elec|ubmi)t|(?:un)?load|dragdrop|resize|focus|blur)\b\W*?=|abort\b)|(?:l(?:owsrc\b\W*?\b(?:(?:java|vb)script|shell)|ivescript)|(?:href|url)\b\W*?\b(?:(?:java|vb)script|shell)|background-image|mocha):|type\b\W*?\b(?:text\b(?:\W*?\b(?:j(?:ava)?|ecma)script\b|[vbscript])|application\b\W*?\bx-(?:java|vb)script\b)|s(?:(?:tyle\b\W*=.*\bexpression\b\W*|ettimeout\b\W*?)\(|rc\b\W*?\b(?:(?:java|vb)script|shell|http):)|(?:c(?:opyparentfolder|reatetextrange)|get(?:special|parent)folder)\b|a(?:ctivexobject\b|lert\b\W*?\())|<(?:(?:body\b.*?\b(?:backgroun|onloa)d|input\b.*?\\btype\b\W*?\bimage)\b|!\[CDATA\[|script|meta)|(?:\.(?:(?:execscrip|addimpor)t|(?:fromcharcod|cooki)e|innerhtml)|\@import)\b)"After successful matching, according to the vulnerability definition file, you can choose to forward to the error page, or you can use replace to disinfect. The replace disinfection table is as follows:
Adding the " " string before and after the XSS attack character will make the attack script unable to run, and will not affect the display content when the browser displays it.
SQL injection attack
The principle of SQL injection attack is as follows:
The attacker injects a malicious SQL command (drop table users;) into the HTTP request. When the server uses the request parameters to construct the database SQL command, the malicious SQL is constructed together and executed in the database.
If there is an input box in the Web page that requires the user to enter a name, and an ordinary user enters an ordinary name Frank, then the final HTTP request submitted is as follows:
http://www.a.com?username=Frank
After the server processes the calculation, the SQL query command submitted to the database is as follows:
Select id from users where username='Frank';
But a malicious attacker might submit an HTTP request like this:
http://www.a.com?username=Frank';drop table users;--
That is, the entered uername is:
Frank';drop table users;--
In this way, after processing by the server, the final SQL generated is like this:
Select id from users where username='Frank';drop table users;--';
In fact, these are two SQLs, a select query SQL, and a drop table SQL to delete the table. After the database completed the query, it deleted the users table and the system crashed.
The rule regular expression for handling SQL injection attacks is as follows.
(?:\b(?:(?:s(?:elect\b(?:.{1,100}?\b(?:(?:length|count|top)\b.{1,100}?\bfrom|from\b.{1,100}?\bwhere)|.*?\b(?:d(?:ump\b.*\bfrom|ata_type)|(?:to_(?:numbe|cha)|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebtask)|ql_(?:longvarchar|variant))|xp_(?:reg(?:re(?:movemultistring|ad)|delete(?:value|key)|enum(?:value|key)s|addmultistring|write)|e(?:xecresultset|numdsn)|(?:terminat|dirtre)e|availablemedia|loginconfig|cmdshell|filelist|makecab|ntsec)|u(?:nion\b.{1,100}?\bselect|tl_(?:file|http))|group\b.*\bby\b.{1,100}?\bhaving|load\b\W*?\bdata\b.*\binfile|(?:n?varcha|tbcreato)r|autonomous_transaction|open(?:rowset|query)|dbms_java)\b|i(?:n(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)\b|(?:f(?:\b\W*?\(\W*?\bbenchmark|null\b)|snull\b)\W*?\()|(?:having|or|and)\b\s+?(?:\d{1,10}|'[^=]{1,10}')\s*?[=<>]+|(?:print\]\b\W*?\@|root)\@|c(?:ast\b\W*?\(|oalesce\b))|(?:;\W*?\b(?:shutdown|drop)|\@\@version)\b|'(?:s(?:qloledb|a)|msdasql|dbo)')After matching the SQL injection attack content from the request, you can set a jump error page or choose to disinfect the replace. The replace table is as follows:
CSRF cross-site request forgery attack
CSRF (Cross Site Request Forgery), the attacker uses cross-site requests to perform illegal operations as legitimate users, such as transfer transactions, posting comments, etc., as shown in the figure:
The main method of CSRF is to use cross-site requests to forge requests as the user's identity without the user's knowledge. Its core is to use browser cookies or server session policies to steal user identities.
SkyNet's anti-attack strategy is that the filter automatically adds a hidden field to the form of all response pages. When a legitimate user submits a request, this hidden field will be sent to the server, and the firewall will check whether the value of the hidden field is correct to determine Whether it is a CSRF attack. The malicious user's request is forged by himself and cannot construct this hidden field, so it will be intercepted by the firewall.
Annotations and exception information leakage
For the convenience of debugging programs or other inappropriate reasons, sometimes program developers will use HTML comment syntax to comment on the program in the front-end page program. These HTML comments will be displayed in the client browser, making it easier for hackers to attack.
In addition, many web servers turn on exception information output by default, that is, the unhandled exception stack information on the server side will be output directly to the client browser. Although this method is good for program debugging and error reporting, it also creates problems for hackers. An opportunity to take advantage of. Hackers deliberately create illegal inputs to cause errors when the system is running, obtain abnormal information, and then search for system vulnerabilities to attack.
The regular expression matching HTML comments is as follows:
“<!--(.|
|
)*-->”
If an HTML comment is matched, the comment is replaced with an empty string.
For abnormal information leakage, SkyNet will check the response status code. If the response status code is a 500 series error, the response body content will be further matched to check whether there is error stack information.