SQL injection, XSS, and CSRF are terms you’ve read about in various technical articles, but I don’t think some people know what they really mean. Next, I will say the meaning of these three terms, I hope to help you.

SQL injection

SQL injection is a type of injection attack, which is caused by the failure to isolate code from data (such as user-sensitive data) in a project, and the incorrect execution of data as part of the code when reading data.

A typical example is using unescaped user input directly as a variable when concatenating SQL statements with strings. At this time, as long as the middle of the SQL statement to modify, such as add drop, delete and other keywords, the execution of the consequences are unimaginable.

Speaking of which, how do you handle this situation? Three aspects:

1. Filter special characters in user input parameters to reduce risks.

2. Do not concatenate SQL statements with strings. Strictly use parameter binding to pass in parameters.

3, rational use of the mechanism provided by the database framework. For example, Mybatis provides the method of passing parameters #{}, do not use ${}, which is similar to string concatenation SQL, use parameterized statements.

To summarize, use parameterized bound SQL variables correctly.

XSS

XSS: XSS is a cross-site Scripting attack. In order to avoid the same name as the front-end CSS, XSS is short for XSS. It is used to insert malicious scripts into HTML pages requested by normal users.

Such attacks are mainly used for information theft and destruction. For example, in the weibo XSS attack in 2011, the attacker took advantage of the failure to filter the action-data vulnerability effectively in the microblog publishing function, and carried the URL containing the attack script when the microblog information was released. When users visited, malicious scripts would be loaded, resulting in a large number of users being attacked.

To protect against XSS, mainly by filtering or escaping data entered by users, you can use the utility class HtmlUtil provided by the framework. In addition, the front end uses a secure API to display the data when the browser displays it. For example, use innerText instead of innerHTML.

CSRF

Cross-site request forgery refers to the act of impersonating a user to send a request without the user’s knowledge to perform malicious operations on the current logged in Web site, such as Posting malicious messages and changing passwords.

Roughly speaking, XSS overlaps with XSS, where hackers steal login information from the user’s browser and impersonate the user to perform operations. The latter is to put malicious code in the HTML requested by normal users. The problem of XSS is that the user data is not escaped and filtered. The CSRF problem occurs when the HTTP interface is not protected against dishonest calls.

Ways to prevent CSRF vulnerabilities:

1. CSRF Token authentication: Using the same-origin restriction of the browser, CSRF verifies the Token in the Cookie before the HTTP interface is executed.

2, human-computer interaction, such as SMS verification code, interface slider.

I also had a thought in the conference earlier, in terms of man-machine verification, if you don’t use the verification code, you use the slider on the interface, and the slider is a third party. In the APP registration, login using this man-machine verification, if the third party has a problem, then their APP will completely collapse, the APP after the release of what can not be changed.

Can you think of a solution to this problem? In the next article, I’ll talk about the results of the discussion.

I hope this will be helpful for everyone, and if you have any suggestions, let me know in the comments section.

I will continue to share things like this. Your attention, retweets and likes are the biggest support for me. Thank you.