SQL injection, XSS attack, CSRF attack

SQL injection, XSS attack, CSRF attack SQL injection what is SQL injection

SQL injection, as the name implies, is an attack by injecting a SQL command, or rather an attacker inserting a SQL command into a Web form or a query string that requests parameters to submit to the server, allowing the server to execute a malicious SQL command written.

For Web developers, SQL injection is already familiar, and SQL injection has survived for more than 10 of years, and there are already very mature ways to prevent it, so there are very few vulnerabilities in current Web applications that allow SQL injection attacks. Unless you're a starter developer, you're still using the old technology for development (like Java Statement and PreparedStatement)

Why SQL injection vulnerabilities occur

From the above, SQL injection is an attack by having the server execute a malicious SQL command, so the main problem is how the server generates the SQL statement. In fact, most of the WEB systems that have SQL injection vulnerabilities, when generating SQL statements, use the way of stitching strings, and do not test and filter the parameters to be assembled into SQL statements.

Common scenarios

The following is a user login scene to explain
Now we have a user table in our database (T_user), assuming that there are only two elements in the table, the user name and password, respectively.
Then in the Web application, generally in the user login, the method of verification is generally through the account and password to get the data table in the existence of such a record, the presence of the user, the absence of the return null;
Then our SQL statement would probably look like this.
SELECT username from T_user WHERE username = ' xxx ' and password = ' xxx '

Take Java as an example (using the form of a stitched string)

    public User login(User user) {
        // 第一步：构造 SQL 语句，在拼接字符串需要添加‘‘
 // 这是因为数据库中字符串值要用 ‘‘ 包住
 String sql = "SELECT username FROM t_user "
 + "WHERE username = ‘" + user.getUsername() + "‘" 
 + "AND password = ‘" 
 + user.getPassword() + "‘";

 // 第二步：执行查询并返回查询的结果
 ...
 }

So at this point I'll enter the following information on the landing page
Account number: 1 ' or 1
Password: xxx (optional)
Then the server generates such an SQL statement
SELECT username from T_user where username = ' 1 ' or 1 and password = ' xxx '

Know a little about the logic of the people know that the condition of the query will always return records, there is a record on behalf of the success of the login, the user does not need to know the correct account password can log on the system, if it is logged into the front desk, that may be OK; But if he got the backstage management link, landed in the backstage, Then your system may be compromised by malicious means.

You can see from the code that if you generate SQL statements in the form of this concatenation string, this gives you an opportunity to inject SQL.

Summarize

When developing a Web application, you should try to avoid using stitching strings to generate SQL statements, and pay particular attention to checking SQL statements that contain parameters of the stitched string type, as much as possible to test for SQL injection vulnerabilities.

XSS attacks what is XSS

XSS, full name: Cross-site Scripting (cross-site scripting) is one of the most dangerous and pervasive vulnerabilities in current Web applications. An attacker attempts to inject malicious script code into a trusted website to perform malicious action, and when a user browses a page containing a malicious script using a browser, the malicious script is executed, which in turn affects the user (such as a closed web site, stealing a user's cookie information and masquerading as a user), and so on.
He is similar to SQL injection, and is also attacked by injecting malicious instructions. But SQL injection is performed on the server side, and XSS attacks are performed on the client, which is their essential difference.

Types of XSS

The classification of XSS attacks is not standard, but is generally divided into three categories:

• Reflective XSS (non-persistent cross-site attack)
• Storage-type XSS (persistent cross-site attack
• Dom Based XSS (DOM-based cross-site scripting attack)

Here are just a few examples to illustrate what the above three categories of XSS attacks are, respectively.

Reflective XSS (non-persistent cross-site attack)

In general, the use of certain pages of the site will directly output the characteristics of the request parameters, through the URL of the request parameter contains malicious script, causing the user to open the URL, the execution of malicious script.

Example: http://localhost:8080/test.jsp?abc= <script>alert ("123") </script>
When the user accesses this page, it will trigger the popup window.

Of course, the general XSS attack will not be so simple as to let you play a window, maybe he will let you constantly play windows (to you prank), may also steal your information, etc., and generally this form of URL will feel very strange, which has users to open this strange URL, so the general will be a certain packaging to deceive users.

Storage-type XSS (persistent cross-site attack)

This type of attack is usually through form input (such as publishing articles, reply comments and other functions) to insert some malicious script, and save to the database, when other users load the corresponding page, the script will be loaded and executed.
This type of attack is more damaging than a reflective XSS because it affects not just a user, but a large number of users, and that type can also be worm-propagated; As in previous post-paste and Weibo events, users visited pages containing malicious scripts, and users ' cookie information was stolen, And immediately use the user's account to post a new post or microblogging and inject malicious script, so that the malicious script is continuously propagated.

Dom Based XSS (DOM-based cross-site scripting)

What is the difference between a DOM-based cross-site script and the previous two types? The way it is injected is based on the previous two types, except that the injected script is implemented by changing the DOM. One of the benefits of using this approach is that it is not easily discoverable from the source code.

Causes of XSS Attack vulnerability

The main reason is similar to SQL injection, because the developer does not encode and filter user input. Another reason is that there are many variants of this attack method, and it is very difficult to design an XSS filter that can be fully defended.

How to protect against XSS

Based on the cause of the above vulnerability, if we want to defend against this kind of attack, we need to start from the source (user input), a set of reasonable and safe XSS filtering rules.
Here are some ways to filter

• Escape HTML tags and some special symbols

  This method is a very simple filtering method, simply escaping some HTML tags and attributes, such as < escaped into &lt, so that the script like <script>xxx</script> will not run. Of course, simple filtering means that it can easily be bypassed.
  In addition, if you need to use a feature rich in text, the use of such filtering will make the rich text lose its effect.

• Use whitelist, blacklist to filter

  A whitelist or blacklist is a definition of what can be passed and what is not. such as common <b>, <p>; , < tags, such as JavaScript, <a>, <script>, <iframe>, onload, and so on, can be escaped by some properties.
  Of course the use of this method also has its own shortcomings, you can not be poor to cite all the elements, may also be some elements in the blacklist, but in some cases it is necessary to use, which requires us to design the XSS filter when the balance, the most reasonable and best suited to the needs of the design.

Summarize

As a web developer, you should be able to understand how to do XSS attacks, not to be a hacker to attack other people's websites, to steal other people's information, but to understand what XSS attack scenarios, to understand the cause of the vulnerability, to think about why this bug was created, How to fix this bug. If you want to design a better XSS filter, you have to know what attack methods are needed to think more comprehensively.

Note: The above example, running in the browser does not necessarily succeed, the browser has its own defense mechanism, then the simple attack mode, the General browser itself has been blocked, if you want to really test, you go to Google a high-level XSS injection method to learn

CSRF attack what is CSRF

CSRF, full name: Cross site request forgery (outbound domain requests forgery). The general attack is to manipulate cookies by requesting a forgery to steal the user's cookie information.

The principle of CSRF attack

Suppose you currently have user A, server B, Server C (with malicious script)

　　　

1. First, user A requests a login to Server B, and Server B responds to user A and returns the cookie information for the user who uniquely identifies it.
2. User A, while not exiting Server B (that is, still maintaining session state with Server B), accessed server C with malicious script, Server C responds to user a a malicious page, and the malicious script pretends that user A sends a request to Server B, at which point the Server B is mistaken for user a request and therefore responds and The cookie information for user A is returned.
3. Server C receives user A and Server B cookie information, save it, and use this information disguised as user A to access Server B, and then do the corresponding damage (what do you want to do?)

CSRF the cause of the vulnerability

The main reason is that server B does not have a reasonable test of the originating source of the request, that is to say that the requestor must be a normal user without analysis, and respond to the user information to the illegal molecule.

How to defend against CSRF

Here are two ways to defend against CSRF from the server side

1. Verify the value of the HTTP Referer
2. Using the request token

Verifying HTTP Referer

Everyone familiar with the HTTP protocol knows that the HTTP header has a field of Referer information that records the source address of the HTTP request (that is, where it came from).
Since CSRF attacks forged requests are sent from server C, we prohibit cross-domain access, add filter filtering on the server side, and filter out requests that are not made from this server B, thus avoiding CSRF attacks to some extent.
But it's also flawed:

• Prohibit other people to access you across the domain, then if others through Baidu and other search engines to search you, the Referer is Baidu, the server will think this is not trusted, so refused to respond, so that your Web application is difficult to promote (this is my own thinking, I have not tested)
• There is also a Referer setting problem, although the General browser is not allowed to modify the value, but still exist in the old version of the browser can be modified (such as IE6), so there is still a certain security problem

Using the request token

This approach is designed with reference to the synchronization token, which is the scenario used to prevent the form from repeating the submission.
How the request token works:

1. User A accesses Server B
2. Server B generates random strings in some random generation strategy and saves them as tokens (token) in the session, then carries the response back to the user and saves them as hidden fields in the page
3. Each request will be sent with token feedback to the server
4. The server receives each request, will be advanced Merriness card authentication, if the token verification does not pass, the request is considered illegal, refused to respond.

Because CSRF accesses server B by forging a request on server C, it is not able to get the token string in the page, so it can be defensive in some way.

Summarize

A CSRF attack is a form of attack that requests forgery by using a server that does not recognize the user's type and then steals the user's information to attack. Therefore, to defend against this kind of attack, because from the server side, enhance the recognition of the server, well-designed defense mechanism.

Conclusion

The above is my study of these three kinds of attacks in the collation and introduction, if there is not the right place, please put forward, can also communicate with each other.

SQL injection, XSS attack, CSRF attack