Front-end firewall for XSS vulnerabilities: ready for release

So far, we have listed all solutions that can defend against XSS using front-end scripts. Although it seems complicated and cumbersome, it is not necessary to implement it in theory. Our goal is only to provide early warnings and discover problems, rather than achieving zero drops of water.

In fact, HTML5 has already developed a browser XSS solution-Content Security Policy, and most mainstream browsers have implemented this standard.

Since we use a front-end script to implement it again, we have to take advantage in all aspects.

Compatibility

CSP currently supports most mainstream browsers, and IE10 and 11 support some functions. Of course, IE10 was helpless. If you use a front-end script, you can advance and retreat based on the actual capabilities of the browser.

For the DOM-XSS described in the first article, you can enable it as long as standard event models are supported, so IE9 is fully compatible.

In fact, IE8 has opened the browser API interface and supports native accessors. Therefore, IE8 supports hook programs and intercepts suspicious elements.

In most cases, logs are only reported for warning. For such a low requirement, any version of the browser is completely feasible, and even IE6 is no problem.

Because there are still a considerable proportion of Internet Explorer in China, the Front-End scripting solution can cover a wider user base.

Deployment

CSP is implemented through the HTTP header. Policy configuration is stored in the Content-Security-Policy field, so it must be configured on the Web server. This is difficult to configure for Small and Medium-sized websites built on virtual hosts.

The front-end implementation only needs to insert a script on the page, so there is no need to care about the backend deployment and modify the policy or restart the service, which is much easier to maintain.

However, CSP will support page deployment in the future, and policies can be configured through meta tags, so the practicality will be greatly improved.

Of course, all the problems we face today will eventually disappear through standard improvement and the progress of the times. Therefore, any solution is only to solve the current problem.

Performance

Without a doubt, browser native support is certainly more efficient than the simulation.

I have considered various situations before and need to install various events and hooks, which is very cumbersome. However, this is only the case where theoretically the defense is the strictest. In reality, only warnings are provided, and no monitoring is required.

As a test, we still consider the strictest possible conditions. Based on the results discussed in the previous articles, we made a prototype demonstration.

In order to simulate online products offline, a Chrome plug-in was developed to inject the script into the online page:

The scripts, plug-ins, and network communication used in the page are all monitored on the console and different colors are displayed according to policy matching.

Let's look at the performance impact. Although we have enabled all monitoring, the initialization time is acceptable. (Windows 2.3 64-bit i3 G laptop)

After all, JavaScript hooks are only used to modify variable fields, rather than modifying memory permissions as traditional languages do.

Of course, the content on this page is relatively small and can only be seen in script initialization.

Let's change to a page with a lot of content:

Because the framework page is nested, we mentioned in the discussion of hooks that the new page environment also needs defense, so the initialization of "active defense" is triggered multiple times.

The content of "static scan" is exactly the elements captured by MutationObserver. Because there are many pages, static elements are displayed as HTML documents are downloaded and displayed. Although the total scanning time is not long, the loading time relative to the whole page is not counted.

The content of "Dynamic Scan" is subsequently created through scripts. As the scroll bar is pulled down, the number of scans increases. Since we have hooked up createElement, theoretically the call will be slower. However, in reality, this method is rarely called in a large amount. Most templates are created in batches through innerHTML.

In addition, we also hooked up the common setAttribute method. The statistical results and the "accessors hook" are included in the "property check. However, in reality, this method does not need to be called in most cases. After all, from attribute to property has to go through a string parsing. If property can be directly used, there is no need to set attribute.

Accessors hooks are triggered only when the src attributes of the script and embed elements are modified. These operations are rare, so the extra consumption of attribute scanning can still be ignored.

Policy Configuration

The biggest advantage of using scripts is that its policies can be flexibly configured. Rules can be dynamically generated, and the matching mode is not limited. Wildcards or regular expressions are acceptable. Originally, everything is implemented by scripts, and the path to where to go is completely determined by the script.

Of course, in order to better adapt to CSP standards, we try our best to bring policy norms closer to standards for mutual compatibility.

Because of the flexibility of the script, we support not only wildcards to match the site name, but also regular expressions. In addition, the debugging console allows you to dynamically modify policies to facilitate testing.

Next, we will find a page with XSS and try it now:

Refresh, XSS executed:

Although it is executed in a non-same source, it is also an XSS. Let's test it.

Enable our firewall to add a whitelist policy to the executable module. Only the resources of the current site are allowed, others are intercepted, and alarm logs are sent:

It's time to see a miracle...

Suspicious modules outside the site have been intercepted successfully! Send warning logs to the background at the same time.

Log reporting

In standard CSPs, the reported format is fixed and the information content is limited. But for the script, this is not a problem. You can add the desired information at any time.

You will surely feel that there are not too many reports, and there are only a few vulnerabilities. However, in a broad sense, XSS may not be caused by vulnerabilities.

XSS -- Cross Site Script, as long as it is a Script outside the Site in the page, can be considered. Generally, this vulnerability can only be caused by vulnerabilities. However, in some special cases, any page may contain out-of-site scripts, such as the traffic hijacking discussed earlier or browser plug-ins, are common cases.

Therefore, in addition to online warnings, we can also count the advertising hijacking of operators in various regions, as well as some Web plug-ins.

Of course, it is easy to bypass. As long as we filter out our defense scripts on the traffic or block log sending, we will not be able to know.

Postscript

In fact, the final solution has been launched. Although only a few users are sampled, millions of warning logs are still returned. Almost all of them are ad hijacking and browser plug-ins. Even if there are vulnerabilities, we cannot learn them at the moment. We cannot analyze and reproduce them one by one. Therefore, we also need an efficient reproduction system to help us achieve automated reproduction.