Introduction to common security issues in front-end development

Frequently asked questions:

(Learning video sharing: Programming video)

1. Cross-site scripting attack (XSS Attack)

XSS (Cross Site Scripting), cross-site scripting attack. XSS is one of the common web attack technologies. The so-called cross-site scripting attack refers to the following: malicious attackers inject malicious Script code into web pages. When users browse these web pages, the malicious code will be executed, which can cause harm to users. Various attacks such as stealing cookie information and session hijacking.

Solution:

(1) Input filtering. Never trust user input and perform certain filtering on user-entered data. For example, whether the input data conforms to the expected format, such as date format, email format, phone number

code format, etc. This can provide preliminary defense against XSS vulnerabilities. The above measures only restrict the web side. Attackers can still bypass the front-end input restrictions by using packet capture tools such as Fiddler and modify the request to inject attack scripts.

Therefore, the backend server needs to filter or escape special dangerous characters after receiving the data input by the user, and then store it in the database. (2) Output encoding. The data output from the server to the browser can be encoded or escaped using the system's security functions to prevent XSS attacks. In PHP, there are two functions htmlentities() and htmlspecialchars() that can meet security requirements. The corresponding JavaScript encoding method can use JavascriptEncode. (3) Security coding. Development should try to avoid Web client document rewriting, redirection or other sensitive operations, and avoid using client data. These operations should be implemented on the server side using dynamic pages as much as possible. (4) HttpOnly Cookie. The most effective defense method to prevent XSS attacks from stealing user cookies. When a web application sets a cookie, set its attribute to HttpOnly to prevent the cookie of the web page from being stolen by malicious JavaScript on the client side and protect the user's cookie information. (5) WAF (Web Application Firewall), Web application firewall, its main function is to prevent common Web vulnerability attacks such as web Trojans,

XSS and CSRF. Developed by a third-party company, it is popular in corporate environments.

2. Cross-site request forgery (CSRF attack)

CSRF (Cross Site Request Forgery), that is, cross-site request forgery, is a common web attack, but many developers are not aware of it Very strange. CSRF is also the most easily overlooked type of Web security. Website attack

Principle of CSRF attack: The victim user of the CSRF attack process logs in to website A, enters personal information, and saves the cookie generated by the server locally. Then click on a malicious link built by the attacker on website A to jump to website

, and then website B carries the user cookie information to visit website B. This makes website A appear to be the user's own visit, thus To perform a series of operations, the most common one is transfer.

Solution:

(1) Verification code. During the interaction between the application and the user, especially in core steps such as account transactions, the user is forced to enter a verification code to complete the final request. Under normal circumstances, the verification code is good enough to contain

CSRF attacks. However, adding verification codes reduces the user experience, and the website cannot add verification codes to all operations. Therefore, verification codes can only be used as an auxiliary means to set verification codes at key business points. (2) Referer Check.

HTTP Referer is part of the header. When the browser sends a request to the web server, it usually brings the Referer information to tell the server which page it is linked from. The server can use this to obtain some information for processing

reason. CSRF attacks can be defended against by checking the source of the request. The referer of a normal request has certain rules. For example, the referer of a form submission must be a request initiated on that page. Therefore, we can determine whether it is a CSRF attack by checking whether the value

of the http header referer is this page. But in some cases, such as jumping from https to http, the browser will not send the referer for security reasons, and the server will not be able to check. If other websites in the same domain as this website have XSS vulnerabilities, attackers can inject malicious scripts into other websites. If the victim enters such a URL in the same domain, he will also be attacked. For the above reasons, Referer Check cannot be completely relied on as the main means of defending against CSRF

. However, the occurrence of CSRF attacks can be monitored through Referer Check. (3) Anti CSRF Token. The current relatively complete solution is to add Anti-CSRF-Token, that is, add a randomly generated token in the form of a parameter to the HTTP request when sending a request, and establish an interceptor on the server to verify this token. The server reads the token value in the browser's current domain cookie, and verifies whether the token

in the request and the token value in the cookie exist and are equal, and then considers this to be a legitimate request. Otherwise, the request will be considered illegal and the service will be refused. This method is much safer than the Referer check. The token can be generated after the user

logs in and placed in the session or cookie. Then the server takes the token out of the session or cookie at each request, and The token in this request is compared. Due to the existence of the token, the attacker can no longer construct

Output a complete URL to implement CSRF attack. However, when dealing with the coexistence problem of multiple pages, when a certain page consumes the token, the forms on other pages still save the consumed token, and a token error will occur when the forms on other pages are submitted. .

3. SQL injection attack

SQL injection (SQL Injection), when the application passes SQL (Structured Query Language, Structured Query Language) to the backend database, the attacker will Insert SQL commands into Web form submissions or enter domain names or query strings for page requests, ultimately tricking the server into executing malicious SQL commands.

Solution:

(1) Prevent Sensitive system information is leaked. Set the php.ini option display_errors=off to prevent sensitive information errors from being output on the web page after an error occurs in the php script, giving attackers an opportunity to take advantage. (2) Data escape. Set the php.ini option magic_quotes_gpc=on, which will automatically add \ in front of all '(single quotes), "(double quotes), \(backslash), blank characters, etc. in the submitted variables. Or use The mysql_real_escape() function or addslashes() function escapes input parameters. (3) Add blacklist or whitelist verification. Whitelist verification generally refers to checking whether user input conforms to the expected type, length, value range or other formats Standard. Blacklist verification means that if the user input contains obvious malicious content, the user request will be rejected. When whitelist verification is used, blacklist verification is generally used.

4. File upload Vulnerability

The upload vulnerability was most rampantly exploited by hackers in the DVBBS6.0 era. The upload vulnerability can be used to directly obtain WEBSHELL. The harm level is super high. The upload vulnerability is also a common vulnerability in current intrusions. This vulnerability allows users to Uploading arbitrary files may allow attackers to inject dangerous content or malicious code and run it on the server. The principle of the file upload vulnerability: Because the file upload function implementation code does not strictly limit the file suffix and file type uploaded by users, allowing attackers to By uploading arbitrary PHP files to a web-accessible directory and being able to pass these files to the PHP interpreter, you can execute arbitrary PHP scripts on the remote server.

Solution:

(1) Check whether the server has determined the type and suffix of the uploaded file. (2) Define a whitelist of uploaded file types, that is, only the types of files in the whitelist are allowed to be uploaded. (3) The file upload directory prohibits script parsing to avoid attackers. Secondary attack. Info vulnerability. Info vulnerability is that CGI outputs the input parameters to the page as they are, and the attacker achieves the purpose of deceiving the user by modifying the input parameters.

Detailed introduction:

Website Security

The above is the detailed content of Introduction to common security issues in front-end development. For more information, please follow other related articles on the PHP Chinese website!