XSS Front End Firewall (5): Ready to prepare

So far, we've enumerated the scenarios that can be used to defend against XSS with front-end scripting.

Although seemingly complex and cumbersome, those are theoretical discussions that are not necessarily realized in practice. Our goal is only to warn, to find the problem, not to achieve the degree of watertight.

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

Now that we re-implement it with a front-end script, we have an advantage in every aspect.

Compatibility

Most of CSP's current mainstream browsers are supported, IE10, 11 support some features. For IE10 before, of course, there is nothing to do. If you use a front-end script implementation, you can retreat based on your browser's actual capabilities.

For the first introduction of the DOM-XSS, as long as the support standard event model can be opened, so compatible with IE9 is completely feasible.

In fact, IE8 has opened the browser API interface and supported the operation of the native accessor. Therefore, IE8 is a support hook program, and can intercept suspicious elements.

Considering the actual situation, most of the cases do not intercept, just report logs for warning. For such a low demand, any version of the browser is completely feasible, and even IE6 is not a problem.

Because the domestic IE browser still occupies a considerable proportion, so the use of front-end scripting scheme, can be covered to a wider user base.

Deployment

The CSP is implemented via the HTTP header, and the policy configuration is stored in the Content-security-policy field, so it has to be configured on the WEB server side. This is for some small and medium-sized Web sites using virtual hosting, configuration is more troublesome.

And the front-end implementation simply insert a script on the page, completely do not care about the back-end deployment, modify the policy without restarting the service, maintenance is much easier.

However, the future CSP will support page deployment and can be configured with meta tags, so usability can be greatly improved.

Of course, the problems faced today will eventually disappear through the improvement of standards and the progress of the Times. So any solution is just to solve the current problem.

Performance

There is no doubt that browser-native support is certainly more efficient than simulation.

Before considering a variety of situations, the need to install a variety of events and hooks, feeling very cumbersome. However, it is only theoretically the most stringent defense situation, the reality of the basic only as an early warning, do not need to monitor full open.

As a test, we still consider the most stringent situation. Based on the results of the previous articles, we made a prototype demonstration.

To be able to simulate online products offline, a Chrome plugin was made to inject the script into the online page:

The scripts, plugins, network communication, etc. used in the page are monitored in the console, and different colors are displayed according to the policy match.

Then look at the performance impact. Although we have all the monitoring turned on, it is still acceptable to initialize the time spent. (test environment i3 2.3G notebook Win7 64-bit)

After all, the JavaScript hooks are just the fields that modify the variables, not the memory permissions that the traditional language has to modify, and so on.

Of course, this page content is relatively small, can only see the script initialization situation.

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

Due to the nested frames page, we mentioned in the discussion of the hooks that the new page environment also needs to be defended, triggering the initialization of multiple "active defenses".

The content of "static Scan" is exactly the element captured by Mutationobserver. Because the content of the page is very numerous, the static element is also displayed along with the download side of the HTML document. Although the cumulative scan time is not small, but relative to the entire page load of a few seconds, it is basically negligible.

The content of the dynamic scan is later created by a script. As the scroll bar pulls down, the number of scans is increasing. As we hook up the createelement, the call is theoretically slower. However, in reality, very few will be a large number of calls to this method, mostly using templates through InnerHTML batch creation.

In addition, we hook up the common method of SetAttribute, the statistical results and "accessor hooks" are included in the "attribute test". However, most of the situations in the reality do not need to call this method, after all, from the attribute to the property has to go through a string parsing, can directly use the property is completely unnecessary to setAttribute.

The accessor hooks, which are only triggered when modifying the SRC attribute of the script, embed these elements, are inherently rare, so the additional consumption of the property scan can be ignored.

Policy configuration

The biggest advantage of using scripts is that their policies can be flexibly configured. Rules can be generated dynamically, matching is not limited to the mode, wildcard or regular can be. It's all a script implementation, and it's entirely up to the script to decide where to go.

Of course, in order to better adapt to the CSP standard, we try to keep the policy specifications close to the standard in order to be compatible with each other.

Because of the flexibility of the script, we not only support wildcard characters to match the site name, but the regular expression is also fully supported. At the same time, in order to facilitate testing, the debug console can dynamically modify the policy.

Below, we find a page with XSS in it and try it out immediately:

Refresh, XSS performed:

Although the non-homologous execution, but at least a XSS. We're going to test it.

Then turn on our firewall and whitelist the executable module with the White list policy. Only the resources of the current site are allowed, others are blocked, and an alarm log is sent:

The moment of miracles comes ...

The suspicious module outside the station has been successfully intercepted! Start sending alert logs to the background at the same time.

Log escalation

In a standard CSP, the escalated format is fixed and the information content is limited. But for scripts, none of this is a problem, and you can add the information you want to get at any time.

You will certainly feel that the number of reports is not too much, there are only a few loopholes. However, the generalized XSS is not always caused by a vulnerability.

Xss--cross site script, as long as the page is outside the station scripts, can be counted. Usually only caused by the vulnerability, but in some special occasions, any page can appear outside of the script, such as the previous discussion of traffic hijacking, or browser plug-ins, are very common situation.

Therefore, in addition to the online alert, we can also count the various regional operators of the ad hijacking, as well as some Web plug-ins.

Of course, it's easy to get around. As long as we filter our defense scripts on the traffic, or block the log sending, we are not aware of it.

Postscript

In fact, the final plan is on-line. Although a very small number of users are sampled, millions of alert logs are still returned. Almost all are ad hijacking and browser plug-ins, even if the existence of loopholes temporarily can not be known, we can not analyze the recurrence. Therefore, we also need a set of efficient replication system to help us achieve automated replication.

XSS Front End Firewall (5): Ready to prepare