Monitor cross-site resources with onload events

Used CSP is very depressed, reported only the site name of the violation, but there is no specific path. Is this a flaw or a deliberate design?

Obviously, CSP is customized for security, the inside of the specification must be strictly formulated, otherwise it will bring new security problems. If you support the escalation of the detailed path, what is the problem?

Because the CSP reports all requests, even redirects, it can be used to probe the redirected addresses. If the logged-on user accesses login.xx.com to Xx.com/username, then the attacker designs a page that allows only the pre-redirect rules, and after the user accesses, the redirected URL is escalated to the attacker as a violation address, including the user name.

If the escalation of detailed paths is supported, this is simply a disaster, which is used to detect the user's private information. In fact, only host names are currently reported, and can be exploited, for example, by using content-security-policy for Evil.

However, the new specification is always improving, and in the future it may only escalate the URL before redirection. But before this, we can only accept these chicken report log.

The rules are inflexible.

CSP currently only supports whitelist lists, which is somewhat inflexible.

To make things worse, there is no way to inherit and share between different rules. For example, there is a rule by default default-src , but other rules override it instead of inheriting it. This leads to a lot of repetition between the rules, making the entire string verbose.

Unable to interact with the page

The monitoring and escalation of CSP is handled automatically in the background of the browser, without providing an event for the page to interact with.

This can only be enforced in a uniform manner, and cannot be handed over to the page script, better from the definition of processing.

Escalation mode is not controllable

If there are many options to deal with, then unified processing is understandable.

In fact, there is no alternative to the way and format of CSP reporting. It can only be submitted using POST + JSON, and the fields are cumbersome, and even the whitelist list in the rules is sent up.

In addition, it is not possible to set a cache time to control the repeat escalation interval. When configuring white list omissions, there will be a large number of false positives, serious consumption of resources.

Wasting bandwidth

In newer Chrome, you can use META tags to define CSP rules on front-end pages, but other browsers are still not supported.

In order to be unified, most still use the HTTP header input method. Because the rules are usually very long, each page access will add an additional hundreds of bytes.

Maintenance cumbersome

If it is opened through a WEB service, it is troublesome to modify the configuration or even restart the service every time the policy is adjusted.

Not high compatibility

Currently only a high-level browser support, and the IE series are almost not very good support.

If some attacks only compete against the lower version of the browser, then there is a high likelihood of a large number of omissions.

Simulation of the CSP principle

In fact, a few years before the CSP appeared, there was a plan to monitor the cross-site resources and share the following.

JS is known, if you need to give a large number of elements to listen to events, do not need to bind on each element, as long as they listen to their container. When a specific event bubbles up to the container, it is event.target to know which element produced it.

When elements such as scripts, pictures, frames are loaded, the OnLoad event is generated, and all elements are in the top-level container of the document. So we listen to the OnLoad event of the document and we can learn all the elements that load the resource.

However, the OnLoad event is quite special and cannot be monitored by bubbling. However, in the DOM-3 Standard Model, there is also a concept of "capture", which is why AddEventListener has a third parameter.

Monitor cross-site resources with onload events