CSRF (Cross-site request forgery: cross-site request forgery) attack.
The purpose of CSRF: Sending emails, sending messages, stealing your account, even purchasing goods, virtual currency transfer...The problems caused include: personal privacy leakage and property security.
You can understand CSRF like this: the attacker has stolen your identity and sent malicious requests on your behalf.
One day you log in to your bank account to operate XXX, then when you visit some illegal websites, if there is no same-origin policy, it initiates a request to the bank's interface (the browser will automatically bring the relevant cookie), assuming the bank If the server of is judging the login status based on cookies, an illegal website is equivalent to logging in to your bank account...
The essence of the CSRF attack is derived from the implicit authentication mechanism of the WEB! Although the WEB authentication mechanism can guarantee that a request comes from a user’s browser, it cannot guarantee that the request was approved by the user.
Solution:
1 "Using hash to verify that this is the request sent by the user, which can be attacked by XSS.
2 "Using the verification code to completely prevent CSPF attacks.
3" Verifying the referer attribute in the request header and prohibiting requests from third-party websites.
4 "Token can be used to generate a random number in the backend, one copy is stored in the cookie, and the other is stored in the browser. The background control can only leave a message and other operations when the two numbers are equal. Disadvantages: If the user opens multiple interfaces to the website in the browser, only the last page can be operated effectively.
5 "Different forms contain a different pseudo-random value, but this method must pay attention to the compatibility of parallel sessions. That is, each time the form is loaded, the site generates a pseudo-random value to overwrite the previous pseudo-random value. The user can only successfully submit the form he opened last, because all other forms contain illegal pseudo-random values. Care must be taken to ensure that CSRF protection measures do not affect tabbed browsing or browsing a site with multiple browser windows.
XSS (Cross Site Scripting): Cross-site scripting attacks, there are three types: reflective XSS (non-persistent), stored XSS (persistent) and DOM XSS
XSS application:
hanging horses.
Steal user cookies, account numbers and other information.
DOS (Denial of Service) client browser.
Front-end JS mining.
Phishing attacks, advanced phishing techniques.
Delete the target article, maliciously tamper with the data, and frame the blame.
Hijack the user's Web behavior, and even further penetrate the intranet.
Web2.0 worm broke out.
Worm-style DDoS attacks.
Worm-style horse-hanging attacks, advertisements, browsing traffic, and online data destruction
1. Reflective XSS: When a request is made, the XSS code appears in the URL and is submitted to the server as input. After the server parses the response, the XSS code is sent back to the browser along with the response content, and finally the browser parses and executes the XSS code. This process is like a reflection, so it is called reflective XSS. Its characteristics: it is non-persistent, and it can only be caused by the user clicking a link with specific parameters.
2. Stored XSS: The only difference between stored XSS and reflective XSS is that the submitted code will be stored on the server side (database, memory, file system, etc.), and you do not need to submit the XSS code next time you request the target page
The most typical example is the message board XSS. The user submits a message containing the XSS code and stores it in the database. When the target user views the message board, the content of those messages will be queried from the database and displayed. If the browser finds the XSS code, it will be regarded as normal. The HTML and Js were parsed and executed, which triggered an XSS attack.
3. DOM XSS: The difference between DOM XSS and reflective XSS and stored XSS is that the code of DOM XSS does not require server participation. The triggering of XSS depends on browser-side DOM parsing, which is entirely a client-side matter.
Solution:
1. Escape, escape sensitive characters, turn the> character into'>' <turn into'<'
2. Filter, filter sensitive tags or tag attributes
3. SQL injection: input parameters are not filtered, then Directly spliced into SQL statements, parsed and executed, and achieved unexpected effects called SQL attacks
SQL defense:
-
String length verification, only accept variable values within the specified length range. The SQL injection script will inevitably increase the length of the input variable. Through the length limit, for example, the length of the user name is between 8 and 20 characters. If it exceeds, it will be judged as an invalid value.
-
Escape SQL comment symbols such as single quotation marks and double "-", underscores, percent signs, etc.
-
Format the received parameters, such as the int type conversion after the id parameter value is obtained
-
Never use dynamic assembly SQL. It is recommended to use parameterized SQL or directly use stored procedures for data query access. The main target of SQL injection is dynamically assembled SQL, and the risk of SQL injection can be greatly reduced through parameterized query.
Defense against DDOS attacks:
①Limit the size of uploaded files to prevent denial of service attacks due to exhaustion of memory and disk.
②The maximum POST size allowed by the web server can be configured.
③The size of the uploaded file can be obtained at the code level, and further filtering can be performed according to the different file types.
Defense against upload vulnerabilities:
1. Limit the type of
file upload 2. Limit the size of file upload