IE8 and clickjacking and CSRF Attack and Defense

Yuwen

In recent years, Web security threats have become increasingly serious. Cross-site scripting attacks, cross-site request forgery attacks, and click hijacking attacks have emerged. We know that web security is closely related to browsers, because browsers are the execution environment of web applications, just like desktop applications and operating systems.

So can IE8 bring a breeze to our Web security belt?

I. Increasingly Severe Web security situation

According to Microsoft, IE8 considered existing and emerging Web threats during development.

Among the various Web Application Security Vulnerabilities, one of the most sinister vulnerabilities is called Cross-Site Request Forgery (CSRF), which is called the "Sleeping Giant" in Web vulnerabilities ", it is also difficult to fix such vulnerabilities. The design concept of the browser security model is to allow simultaneous interaction between multiple websites and seamless browsing between sites. The CSRF attack is precisely because of this.

As valuable personal data and other information are constantly migrated from the end user's PC to popular Web applications, CSRF and other Web application vulnerabilities will be increasingly concerned.

Ii. XDomainRequest object emerged

To defend against CSRF attacks, IE8 introduces an XDomainRequest object, which allows cross-origin communication with server permissions and also contains some special limitations to defend against CSRF attacks. End users can exit sensitive websites when they do not use web applications and use InPrivate Browsing sessions to browse pages to reduce the impact of CSRF attacks, because InPrivate sessions will clear cookies, therefore, CSRF attacks cannot be used to replace cached cookies.

However, Web applications must be designed to defend against CSRF attacks. Well-designed Web applications often use a challenge/token or similar policy to check that malicious requests sent by non-victim users come from my protection. Unfortunately, challenges/tokens and similar policies are affected by some vulnerabilities. The first vulnerability is cross-site scripting (XSS ). If a Web application protected by a token contains a cross-site scripting attack security vulnerability, it is likely to cause CSRF attacks due to the theft of the security token.

Fortunately, IE8 contains an XSS filter and some other features that can help defend against XSS attacks and thus reduce the probability of token theft. In addition, click hijacking can be used to assist in the implementation of CSRF attacks. Click hijacking allows you to click a vague or hidden web element without knowing it, leading to unintentional processing. A successful clickjacking attack can be easily resolved by allowing users to confirm their CSRF protection measures.

For example, a network store uses cookies for identity authentication and provides a one-click purchase service. IE8 displays a simulated web shopping site. Below is a picture of a laptop:

498) this. style. width = 498; "border = 0>

A malicious website in the network can construct a page to force a victim page from a legitimate store to embed an iframe and overlay misleading text and images in key parts of the framework.

498) this. style. width = 498; "border = 0>

The above is a malicious page where pictures of a laptop computer are overwritten by a picture of a cat. If the user has logged on to the store, he may be cheated to click the store page without knowing it, resulting in an unintended operation: 498) this. style. width = 498; "border = 0>

The above is a malicious page. The displayed text indicates that the user has purchased a laptop. Of course, this is just a simple clickjacking attack, but it is also a complicated clickjacking attack.

Many methods have been proposed to alleviate the pain of clickjacking. However, they must make some compromises in compatibility and user experience, or they must make major changes to existing standards. Currently, frame busting is the most widely used and simple solution to defend against click hijacking. It can prevent vulnerable pages from being framed, for example, preventing pages from being referenced by iframe. Unfortunately, the frame-busting mechanism usually requires scripts, but we know that bypassing scripts is not impossible.

3. How to combat clickjacking in X-FRAME-OPTIONS

The click Kidnapping Vulnerability was first revealed by Jeremiah Grossman and Robert Hansen in last September. This vulnerability allows hackers to counterfeit legitimate webpages and overwrite forged transparent webpages on legitimate webpages, therefore, the user thinks that the mouse clicks on a valid webpage actually triggers malicious webpage commands.

If the attacker spoofs the online banking webpage, the user may just press a webpage link, but may transfer the money to a strange account, hackers can also exploit this vulnerability to allow users to download malicious programs or execute any function. IE8 introduces a mechanism to prevent the page from being framed to reduce the harm caused by click hijacking.

Web developers can add an HTTP Response Header for the returned HTML page to determine whether the page can be embedded in iframe. If the value of the X-FRAME-OPTIONS is DENY, IE8 does not allow the page to be contained in a framework. If the value is SAMEORIGIN, IE blocks the page only when the top-level browser content is different from the content that contains the X-FRAME-OPTIONS.

For example, ifHttp://shop.example.com/confirm.aspContains a DENY pseudo command, so the page cannot be put into a child frame, no matter where the parent framework is located. Reversely, if the value of the X-FRAME-OPTIONS directive is SAMEORIGIN, the page can be placed into anyHttp://shop.example.com.

When the X-FRAME-OPTIONS stops displaying a page, the browser pops up a local error page describing the limitations and provides a link that opens the frame in a new window. When displayed in a new window, rather than in the sub-frame, the page content cannot be used for click hijacking.

498) this. style. width = 498; "border = 0>

The above is a malicious page. However, the order button from the actual webshop is not displayed when only the cat image is displayed. The error message indicates that the content cannot be displayed in the framework.

By using the X-FRAME-OPTIONS directive, Web developers can immediately help IE8 users mitigate the threat from various Web application attacks. Of course, we want its browser to also implement this X-FRAME-OPTIONS directive, because it is relatively easy to deploy as a defense against clickjacking and has good compatibility.

Iv. Web security has a long way to go

Although Microsoft claims to have fixed the click hijacking vulnerability, this is not an immediate solution because it requires the cooperation of websites and Web developers, rather than directly protecting the security of web users. In addition, it may take a long time for all websites to adopt the Microsoft mechanism. In addition, the solution provided by Microsoft is non-cross-platform, that is, it is only valid for IE8. Another solution released now is the NoScript plug-in designed for Mozilla Firefox, which can disable the Script Function and block attacks using the framework.