HTML5 security risk details: CORS attacks

1. From SOP to CORS

SOP is the Same Origin Policy Same-Origin Policy. It refers to the document or script of one domain and cannot obtain or modify the document attributes of another domain. That is to say, Ajax cannot be accessed across domains. Our previous basic Web resource access policies are built on SOP. It caused a lot of web developers to suffer, and later developed many cross-domain solutions, such as JSONP and flash socket. As shown in:

 

Later, CORS-CrossOrigin Resources Sharing, that is, cross-source resource Sharing, was introduced. It defines a way for the browser to interact with the server to determine whether cross-origin requests are allowed. It is a compromise with greater flexibility, but it is safer than simply allowing all of these requirements. In short, CORS is generated to allow AJAX to implement controllable cross-origin access. For details, see my article "HTML5 security: CORS (cross-origin Resource Sharing) Introduction". As shown in:

 

Currently, W3C official documentation is still working draft, but is moving towards W3C recommendation. However, many modern browsers currently support it.

The server supports CORS mainly by setting Access-Control-Allow-Origin. If the browser detects the corresponding settings, Ajax can be allowed for cross-origin access. For example:

 
Access-Control-Allow-Origin: http://blog.csdn.net
Currently, CORS systems include Face.com and GoogleCloudStorage APIs, which provide third-party access capabilities for open platforms.

Ii. risks brought by CORS

CORS is very useful and can share a lot of content, but there are risks. Because it is completely a blind protocol, it is only controlled through the HTTP header.

Its risks include:

1. The HTTP header can only indicate that the request comes from a specific domain, but it cannot be guaranteed. Because the HTTP header can be forged.

Therefore, unauthenticated cross-domain requests should never be trusted. If some important functions need to expose or return sensitive information, you must verify the Session ID.

2. A third party may be infiltrated

For example, FriendFeed accesses Twitter through cross-origin requests. FriendFeed requests tweets, submits tweets, and performs some user operations. Twitter provides a response. Both of them trust each other, so FriendFeed does not verify the validity of the obtained data. Twitter also provides most of the functions for Twitter.

However, if Twitter is intruded:

FriendFeed always retrieves data from Twitter and displays this information on the page without code or verification. However, after Twitter is infiltrated, the data may be harmful.

Or when the FriendFeed is intruded:

Twitter responds to requests from FriendFeed, such as posting Tweets, changing user names, and even deleting accounts. Attackers can exploit these requests to tamper with user data when the FriendFeed is intruded.

Therefore, it is very important for the requester to verify the validity of the received data and the service provider to expose only the least necessary functions.

3. Malicious cross-origin requests

Even if the page only allows requests from a trusted website, it also receives a large number of cross-origin requests from other domains .. These requests may sometimes be used to perform DDOS attacks at the application layer and should not be processed by the application.

For example, consider a search page. When you request the '%' parameter, the search server returns all records, which may be a heavy computing requirement. To kill this website, attackers can exploit the XSS vulnerability to inject Javascript scripts into a public forum. When a user accesses this Forum, his or her browser repeatedly executes the search request to the server. Or even if you do not use cross-origin requests, you can use an image element that contains the request parameters with a target address to achieve the same purpose. If possible, attackers can even create a WebWorker to execute such attacks. This will consume a lot of resources on the server.

An effective solution is to block illegal requests, such as HTTP headers and parameters, through multiple conditions.

4. Internal Information Leakage

Assume that CORS is enabled for an internal site. If a user on the internal network accesses a malicious website, the malicious website can obtain the content of the internal site through COR (cross-origin request.

5. Attacks against users

The above are all attacks against the server, and risk 5 is for the user. For example, the attacker has identified the SQL injection vulnerability on the productsearch. php page that you can access globally. Attackers do not directly obtain data from their system databases. They may write a JavaScript data collection script and insert this script on their own website or website with XSS problems. When a victim accesses a website containing this malicious JavaScript script, its Browser executes the SQL injection attack against "productsearch. php" and collects all the data and sends it to the attacker. Check that the server log shows that the victim has performed an attack because there are generally no other log records except the HTTP header from Referrer. The victim cannot say that his system has been cracked because there is no trace of malware or system leakage.

Iii. attack tools

Shell of the Future is a reverse WebShell processor that uses HTML5 cross-site requests to hijack sessions.

 

Iv. Defense

1. If you do not trust cross-origin requests without authentication, you must first verify the Session ID or Cookie.

2. For the requester to verify the validity of the received data, the service provider only exposes the least required functions.

3. Use multiple conditions to block illegal requests, such as HTTP headers and parameters.

Original article, reprinted, please note: blog from Jiang Yujie