[network security] web security trends and core defense mechanisms

One 、WEB Causes of safety technology

In the early ： web （World Wide Web） have only Web Site composition , These sites are basically information repositories containing static documents . This information flow is only transmitted one way from the server to the browser . Most sites do not verify the legitimacy of users .

Now ： It is completely different from the early World Wide Web ,Web Most sites on are actually applications . They are powerful , Two way information transmission between server and browser . Much of the information they process is private and highly sensitive . therefore , Safety is of the essence ,Web Security technology also came into being .

Two 、Web Common program vulnerabilities

1.  Imperfect authentication measures ： Such vulnerabilities include various flaws in the application login mechanism , It may enable the attacker to break the password with weak confidentiality , Launch a brute force attack or completely avoid landing .

2.  Imperfect access control measures ： The issues involved include ： Applications cannot provide comprehensive protection for data and functionality , An attacker can view sensitive information stored in the server by other users , Or perform privileged operations .

3. SQL Inject ： An attacker can submit specially designed input through this vulnerability , Interfere with the interaction between the application and the back-end database . An attacker can extract any data from the application 、 Destroy the logical structure , Or execute commands on the database server .

4.  Cross-site scripting ： An attacker can exploit this vulnerability to attack other users of the application 、 Access its information 、 Perform unauthorized operations on their behalf , Or launch other attacks on it .

5.  Information disclosure ： This problem includes the disclosure of sensitive information by applications , The attacker uses this sensitive information to attack the application through defective error handling or other behaviors .

3、 ... and 、 Core security issues

Today, Web The core security issue of the program is ： The user can submit any input . Specific for ：

1. The user can intervene in all data transmitted between the client and the server , Including request parameters 、cookie and HTTP Message header .

2. Users can send requests in any order .

3. Users are not limited to using only one Web Browser access applications . A wide variety of tools can help attack Web Applications , These tools can be integrated into the browser , It can also operate independently of the browser . These tools can make requests that ordinary browsers cannot provide , And can quickly generate a large number of requests , Find and use security issues to achieve their own purposes .

Four 、 Currently for Web The core defense mechanism proposed by security issues

Web Basic security issues for applications （ All user input is not trusted ） Cause the application to implement a large number of security mechanisms to resist attacks . Although its design details and execution efficiency may vary widely , But the security mechanisms adopted by almost all applications are conceptually similar .

Web The defense mechanism adopted by the application consists of the following core factors ：

1. Handle the data and functions that users access the application , Prevent users from gaining unauthorized access .

2. Handle user input to application functions , Prevent bad behavior caused by wrong input .

3. Dealing with attackers , Ensure that the application works properly when it becomes a direct target , And take appropriate defense and attack measures to defeat the attacker

4. Manage the application itself , Help administrators monitor their behavior , Configure its functions .

5、 ... and 、 Theory and concrete measures

For the above four reasons , There are also some theories and practices ：

* 5.1 Handle user access

Almost any application must meet a central security requirement , That is, processing users' access to their data and functions . majority Web Applications use three layers of interrelated security mechanisms to handle user access ：

（1） Authentication

（2） session management

（3） Access control

* 5.2 Processing user input

In many cases , Applications may impose very strict validation checks on some special inputs . for example , The maximum length of the user name submitted to the login function is 8 Characters , And can only contain letters .

In other cases , The application must accept a wider range of inputs . for example , The address field submitted to the personal information page can legally contain letters 、 Numbers 、 Space 、 A hyphen 、 Apostrophe and other characters . However, you can still impose effective restrictions on this field . for example , The data submitted shall not exceed an appropriate length limit （ Such as 50 Characters ）, It shall not contain any HTML Mark （HTML mark-up）.

Several methods of input processing ：

（1）“ Reject known bad input ”

（2）“ Accept known normal inputs ”

（3） Purify the input data ： The malicious characters that may exist in the data are completely deleted , Leave only characters that are known to be safe , Or encode them properly before further processing “ escape ”.

（4） Secure data processing ： Process data submitted by users in an unsafe way , It's a lot of Web The root cause of application vulnerabilities . Sometimes , Safe programming methods can be used to avoid common problems .

（5） Syntax check ： To prevent unauthorized access , The application must confirm that the submitted account belongs to the user who submitted the account before .

（6） Boundary confirmation ： Where server-side applications first receive user data is an important trust boundary , The application needs to take measures here to prevent malicious input .

* 5.3 The necessity of boundary confirmation

When we start analyzing some actual vulnerabilities , Performing this simple input validation is not enough , The reason is ：

（1） Based on the wide range of functions performed by the application and the diversity of technologies , A typical application needs to defend against a large variety of input based attacks , And each attack may use a distinct set of specially designed data , therefore , It is difficult to establish a separate mechanism at the external boundary , Defend against all these attacks .

（2） Many application functions involve combining a series of different types of processes .

（3） Defending against different types of input based attacks may require various validation checks on conflicting user inputs . for example ： Preventing cross site scripting attacks may require “>” character HTML Encoded as “>”, To prevent command injection attacks, you need to prevent including & And ; Character input . occasionally , It is almost impossible to prevent all types of attacks at the external boundary of the application at the same time .

Boundary confirmation （boundary validation） Is a more effective model . here , Each individual component or functional unit of the server-side application treats its input as input from a potentially malicious source . In addition to the external boundary between the client and the server , The application performs data validation on each of the above trust boundaries . This model provides a solution to the problem mentioned above . Each component may defend itself against the special type of specially designed input it receives . When data passes through different components , You can perform a confirmation check on any data value generated during the previous conversion process . and , Since different validation checks are performed at different processing stages , There can be no conflict between them .

* 5.4 Multi step confirmation and standardization

For example, to defend against some cross site scripting attacks , The application may delete expressions from any user submitted data ：<script>, However, an attacker can avoid the filter by applying the following inputs ：<scr<script>ipt>. Cannot run recursively due to filtering , After deleting blocked expressions , The surrounding expressions merge together again , Rebuild the malicious expression . Again , If you perform several confirmation steps for user input , Attackers can use the sequence of these steps to avoid filtering . for example , If the application first recursively deletes the script tag , Then delete the quotation marks , You can use the following inputs to avoid the confirmation check ：<scri*ipt>.

Data normalization （data canonicalization） Will cause another problem . When the user's browser sends input , It can encode these inputs in various forms . The reason for using these coding schemes , To be able to pass through HTTP Secure transfer of uncommon characters and binary data . Normalization refers to the process of converting or decoding data into a common character set . If normalization is not performed until input filtering is implemented , Then the attacker can avoid the confirmation mechanism by using coding . for example , The application may delete apostrophes from user input , To prevent some SQL Injection attack . however , If the application then normalizes the purified data , Then the attacker can use URL The input of the code avoids confirmation .

Sometimes it may be difficult to avoid the problems caused by multi-step validation and Standardization , Nor is there the only solution to such problems .

One solution is to perform cleanup operations recursively , Until the input cannot be further modified . If possible , It's best to avoid clearing some bad inputs , Completely reject this type of input .

* 5.5  Dealing with attackers

The measures taken to deal with attackers generally consist of the following tasks ：

（1） Handling errors

（2） Maintain audit logs

（3） Alert the Administrator

（4） Deal with the attack

* 5.6  Handling errors

A key defense mechanism for an application is to properly handle unexpected errors , Or correct these mistakes , Either send the appropriate error message to the user . Reproduction environment , The application should not return any system generated messages or other debugging information in its response . Overly detailed error messages are very helpful for malicious users to launch further attacks on Applications . In some cases , The attacker can use the defective error handling method to obtain sensitive information from the error message ; here , Error messages become an important channel for attackers to steal data from applications .

majority Web Development language through Try-catch Blocks and checked exceptions provide good error handling support . Application code should make extensive use of these methods to identify special and general errors , And deal with it accordingly . and , You can also configure most application servers , Make it handle application errors that cannot be handled in a custom way , Such as providing an error message that does not contain too much information .

* 5.7  Maintain audit logs

The audit log （audit log） It plays a big role in investigating intrusion attempts against applications . After the invasion , An effective audit log function can help application owners understand what actually happened .

In any security conscious application , The log shall record all important events . Generally, these events should include at least the following .

（1） All events related to authentication function , Such as successful or failed login 、 Password change .

（2） Key transactions , Such as credit card payment and transfer

（3） Any string containing a known attack , An overtly malicious request .

* 5.8  Alert the Administrator

Audit logs help application owners investigate intrusion attempts , If possible , Take legal action against intruders . Abnormal events monitored by alarm generally include the following points ：

（1） Application anomaly , If received by a single IP Address or user makes a lot of requests , Indicates that the application is under custom attack

（2） Abnormal trading ： If the amount of funds transferred in or out of a single bank account is abnormal

（3） Requests containing known attack strings

（4） The data that cannot be viewed by ordinary users in the request is modified .

* 5.9  Manage applications

Many applications generally use the same Web The interface performs management functions internally , This is also its core non security function , under these circumstances , The management mechanism becomes the main attack surface of the application . What attracts attackers is that it can improve permissions , Illustrate with examples ：

（1） The weakness of authentication mechanism enables attackers to obtain administrator privileges , Quickly break through the entire application .

（2） Many applications do not implement effective access control for some of its management functions . Take advantage of this loophole , An attacker can create a new user account with powerful privileges .

（3） The management function can usually display the data provided by ordinary users . Any cross site scripting flaws in the interface can compromise the security of user sessions

（4） Because the administrative user is regarded as a trusted user , Or because penetration testers can only access accounts with low permissions , Therefore, management functions are often not subject to strict security testing . and , He usually needs to perform quite dangerous operations , Including commands to access files on disk or operating system . If an attacker can break the management function , You can use it to control the whole server .