Current common web security vulnerabilities

XSS (Cross Site Scripting) cross-site scripting attack.

1. Stored XSS
hackers mainly embed malicious code wrapped in script tags in the text input area of ​​the site, and then submit it to the server. After the server saves the submitted information, as long as other people browse the page containing the hacker’s malicious code, the malicious The code will execute, possibly compromising other users' information.

2. The reflective XSS
hacker wraps a request containing malicious code on a link, and then induces the user to click. After the user clicks, the request containing the malicious code is submitted to the server, and the server returns the request containing the malicious code to the user, and the malicious code is executed on the client.

3. DOM-type XSS
hackers directly modify the data of the web page and embed malicious scripts during the transmission of web resources on the client side or when the user uses the web page, and the process does not involve the server.

Countermeasures against XSS attacks:

Set sensitive information such as cookies to HttpOnly, and do not allow cookies to be obtained through document and js.
Enable CSP, Content Security Policy, only the content in the whitelist can run normally (JS, Image, etc.).
Strictly correct all input information at the front end and back end, filter out illegal input, and escape commonly used characters that may cause malicious scripts to be embedded, such as angle brackets, double quotation marks and other characters.

HttpOnly is an additional flag included in the http return header Set-Cookie, so it is an additional attribute set by the backend server for cookies. Using the HttpOnly flag when generating cookies helps reduce client script access to protected cookies The risk (if the browser supports it)
will not be able to read the cookie information through the js script, which can effectively prevent XSS attacks.

CSRF (Cross Site Request Forgery) cross-site request forgery

Cross-site request forgery means that hackers can pretend to be users and send requests to the target site, so as to obtain user information and tamper with user data. Cross-site request forgery needs to meet the following three conditions to launch.

①The target site has a CSRF vulnerability.

②The user has logged in to the target site, and the Session is still valid.

③ The user opens a third-party site.

At this time, the third-party site can use the user's Session to forge a request to the target site.

CSRF attack countermeasures:

Set the session validity period to be shorter.
The server judges the source of the request through the Origin and Referer header fields in the request. If the source of the request is different from the target site, there is a high probability that it is CSRF, and the server refuses to execute the request.
When performing some important operations, add Token verification information in the request. Preset random in page interaction elements

3. SQL injection attack

If the filter conditions are not carefully selected when splicing SQL query statements, hackers can input malformed data to distort the semantics. Or guess the SQL query statement through the error statement on the screen.

Countermeasures against SQL injection attacks:

Forbid the target website to access the database by dynamically splicing strings
to reduce unnecessary database error messages.
Filter out unnecessary SQL reserved words such as Where, etc.

4. Click hijacking attack
Click hijacking attack implementation method: by monitoring the mouse movement, the transparent iframe is always under the user's mouse, luring the user to click a seemingly harmless button, but actually clicks the transparent iframe, and then performs some dangerous operations.

Countermeasures against clickjacking attacks:

The server adds the X-Frame-Option response header, so that the browser will prevent the embedded web page from loading.
JS judges whether the domain name of the top-level viewport is consistent with the domain name of this page. If it is inconsistent, the operation is not allowed

5. Man-in-the-middle attack

Man-in-the-middle attacks can still eavesdrop, tamper and identity forgery on the communication information under the HTTPS protocol. As the name implies, a man-in-the-middle attack means that hackers intercept the information of the client and server at the same time, acting as an information transfer station.

First, when the client establishes a connection with the server, the hacker first intercepts the public key that the server intends to transmit to the client, and then generates a pair of asymmetrically encrypted public and private keys. The hacker sends his public key to the client.

After the client receives the hacker's public key, the client generates the symmetric encryption key needed for subsequent communication, encrypts the client's symmetric encryption key with the hacker's public key, and then sends it to the server.

Then the hacker intercepts the data transmitted by the client, decrypts it with the hacker's private key, and obtains the symmetric encryption key of the client. Then encrypt the symmetric encryption key with the server public key and send it to the server.

Finally, the server decrypts and obtains the symmetric encryption key, and the server and the client start to encrypt communication only with the symmetric encryption key, and the hacker has the symmetric encryption key, and can intercept their information, whether it is eavesdropping or tampering with the message Unimpeded.

Man-in-the-middle attack prevention measures:

The client strengthens the verification of the certificate in the public key sent by the server to check whether the certificate is issued by an authority, whether the certificate is still valid, and whether the domain name of the certificate is consistent with the domain name of the server.
The client also has a built-in signature certificate. When establishing a connection with the server, it first checks whether the certificate sent by the server is consistent with the built-in certificate of the client.

6. File upload vulnerability

The server did not verify the uploaded files, allowing hackers to upload malicious scripts and other methods.

Precautions:

Both the front and back ends use the file header to detect the file type, and use whitelist filtering to
completely rename the file after uploading and move it to a non-executable directory
.

This article is reproduced from https://blog.csdn.net/qq_40479037/article/details/129943166 , if there is any infringement, please contact to delete.

Guess you like

Origin blog.csdn.net/qq_44005305/article/details/131457318