Front-end security issues and prevention - 7 common website attacks
1. XSS attack
The full name of XSS is Cross Site Scripting. In order to distinguish it from CSS, it is called XSS. XSS attack refers to the execution of malicious scripts (whether cross-domain or same-domain) in the browser to obtain user information and perform operations.
These operations generally accomplish the following things:
1. Steal cookies.
2. Monitor user behavior, such as entering the account password and sending it directly to the hacker server
3. Modify DOM to fake login form
4. Generate floating window ads on the page
XSS attack means that the attacker wants your browser to execute the JS code he wrote. How? There are generally two types of XSS:
Reflected XSS
Principle:
Reflective XSS, also called non-persistent XSS, means that when a request occurs, the XSS code appears in the request URL and is submitted to the server as a parameter, and the server parses and responds. The response result contains XSS code, and finally the browser parses and executes it
Implementation:
The attacker sends the URL with malicious script code parameters to the user. When the URL address is opened, the unique malicious code parameters are parsed and executed by HTML.
-
The attacker puts the JS code in the URL as a request parameter to induce the user to click
http://localhost:8080/test?username=<script>alert("you are under attack!")</script>
- After the user clicks, the JS is passed to the backend of the Web server as a request parameter
- The back-end server does not check and filter. After simple processing, put it into the body of the web page and return it to the browser
- The webpage returned by the browser parses, and you are recruited!
Stored XSS
The attack script in the above method is directly transferred from the server and then returned to the browser to trigger execution. The difference between the storage type is that the attack script can be stored on the server side, and the attack script will be rendered into the web page when querying later, and returned to the browser to trigger execution. The malicious code will be executed only when the victim browses the page containing this malicious code. Examples of common routines are as follows:
- The attacker’s webpage replies, and the post contains JS scripts
- After the reply is submitted to the server, it will be stored in the database
- Other netizens view the post, query the reply content of the post in the background, build a complete web page, and return to the browser
- The netizen's browser renders the returned webpage, and he is recruited!
Prevent XSS attacks
- A belief: Don't trust the user's input, escape or replace special characters such as "<", ">" to make them unexecutable.
- Two uses: use CSP, use the HttpOnly attribute of Cookie.
2. DDoS attack
DDOS is the abbreviation of Distributed Denial of Service in English. Any behavior that can prevent legitimate users from accessing normal network services is a denial of service attack. Denial of service attack is also called "flood attack". Common DDOS attack methods include SYNFlood, ACK Flood, UDP Flood, ICMP Flood, TCP Flood, Connections Flood.ScriptFlood, Proxy Flood, etc.
- SYN/ACKFloodG master: This attack method is the classic and most effective DDOS method, which can kill the network services of various systems, mainly by sending a large number of SYN or ACK packets with forged source IP and source port to the victim host, causing the host Most of the Jintong firewalls are unable to defend against such attacks due to exhaustion of cache resources or busy sending response packets, resulting in denial of service.
- TCP full connection attack: TCP full connection attack is to use many zombie hosts to continuously establish a large number of TCP connections with the victim server until the memory and other resources of the server are exhausted and dragged, resulting in denial of service. The characteristics of this attack It can bypass the protection of general firewalls to achieve the attack purpose. The disadvantage is that many zombie hosts need to be found, and since the IPs of zombie hosts are exposed, they are easy to be tracked.
Prevent DDoS attacks
- Close unnecessary services or ports:
This is also the most common practice of server operation and maintenance personnel. In the server firewall, only the used ports are opened, such as port 80 of the website web service, port 3306 of the database, port 22 of the SSH service, etc. Close unnecessary services or ports, filter fake IPs on the router - Bandwidth expansion (provide margin bandwidth):
Through server performance testing, evaluate the bandwidth and number of requests that can be tolerated under normal business conditions. When purchasing bandwidth, ensure that there is a certain amount of surplus bandwidth, which can avoid the situation that the bandwidth is greater than the normal usage and affect normal users when attacked.
3. CORS attacks
risk point:
(1). Set Access-Control-Allow-Origin to *, and do not carry session authentication, which means that the information is published on the whole network.
(2). The http header can be forged. HTTP can be forged, which means that the domain name (origin) in the HTTP header can be fake, so cross-domain needs to cooperate with authentication, so remember to bring session id when cross-domain.
(3). Even if the session id is used, the third party may be hacked, which will lead to information leakage of the source site
(4). Internal information leakage, internal members open an evil website, resulting in leakage of personal session information, then the data of the internal website will be leaked
(5). In addition, if Access-Control-Allow-Origin is not set, and permission control is done on the request site, information leakage can be prevented. When the permission error is returned, the requested information has actually reached the client.
(6). CORS cannot carry session information by default, but if withCredentials is set to true, it can be carried, so it is best to set this attribute to false. In case it needs to be set to true, please set it on Access-Control-Allow-Origin Set a specific domain name do not use *
Prevent CORS attacks
- Do not use * for Access Control-Allow-Origin
- To verify session information for cross-domain requests.
- Strictly review request information, such as request parameters and http header information.
4. CSRF attack
The full English name of CSRF is Cross-site request forgery. Phenomenon: There is a website that is the same as the official website, and the submission path of the official website is changed, or cookies are submitted together, causing the submitted data to flow into external websites and leak secrets.
There are three necessary conditions for launching a CSRF attack:
- First, the target site must have a CSRF vulnerability
- Second, the user has to log in to the target site and maintain a login status of the site on the browser
- The third one requires users to open a third-party site, which can be a hacker's site or some forums.
That is to use the verification vulnerability of the server and the user's previous login status to simulate the user's operation
key point:
1. The user logs in to trusted website A and generates a cookie locally
2. Visit dangerous website B without logging out of website A
Prevent CSRF attacks
- To prevent CSRF attacks, we can set some key cookies to Strict or Lax mode according to the actual situation, so that these key cookies will not be sent to the server during cross-site requests, thus making the hacker's CSRF attack invalid.
- Using CSRF-token: the user must enter the verification code, mobile phone verification code, Add token for secondary verification to enhance security
5. SQL injection attack
The core of the SQL injection attack is to let the web server execute the SQL statement expected by the attacker in order to obtain the interested data in the database or perform operations such as reading, modifying, deleting, and inserting the database.
The conventional routine of SQL injection is to place the SQL statement in the form or request parameters and submit it to the back-end server. If the back-end server does not check the input security and directly takes out the variables for database query, it is very easy to be tricked.
Examples
For an interface that obtains user information based on user ID, the SQL statement at the back end is generally as follows:
select name,[...] from t_user whereid=$id
Among them, $id is the user id submitted by the front end, and if the front end request is like this
GET xx/userinfo?id=1%20or%201=1
Among them, after the request parameter id is escaped, it is 1 or 1=1. If the backend directly submits the database query without security filtering, the SQL statement becomes
select name,[...] from t_user whereid=1or1=1
As a result, all the data in the user table are found out, which achieves the hacker's goal of leaking data.
The above is just a very simple example. In real SQL injection attacks, parameter construction and SQL statements are much more complicated than this, but the principle is the same
Prevent SQL injection attack
- Add black and white list verification White: data type, length, value range (js regular verification) Black: Contains malicious content to reject the request
- Security monitoring, relying on tools for various security vulnerabilities to monitor security
- Prevent leakage of sensitive information —> reduce user permissions
6. JSON hijacking
JSON is a lightweight data exchange format, and hijacking is the theft of data. Malicious attackers intercept the JSON data that should be returned to the user through certain specific means, and then send the data back to the malicious attacker. This is the general meaning of JSON hijacking. Generally speaking, the JSON data for hijacking contains sensitive information or valuable data
7. HTTP Header Tracking Vulnerability
The HTTP/1.1 (RFC2616) specification defines the HTTP TRACE method, which is mainly used by the client to test or obtain diagnostic information by submitting a TRACE request to the Web server.
When the web server enables TRACE, the submitted request header will be completely returned in the body of the server response, where the HTTP header is likely to include Session Token, Cookies or other authentication information. An attacker could exploit this vulnerability to deceive legitimate users and obtain their private information.
solution:
Disable HTTP TRACE method