X-XSS-Protection vs CSP

问题:

As far as I understand, CSP can be used for all the same things as X-XSS-Protection and more. If you are using CSP, is there any good reason to use X-XSS-Protection as well?

回答1:

is there any good reason to use X-XSS-Protection as well?

With some doubts (see Kevin's comment below) the answer is probably yes.

X-Xss-Protection activates a heuristic, reflected xss detection feature. Reflected xss comes in the form of parameters, which makes it easy to determine the scope of the potential attack.

Browsers execute HTML. By definition browsers cannot provide any guarantees about data safety of server generated HTML code. It is impossible to determine trusted vs malicious javascript... unless you use CSP. CSP allows you to choose what javascript the browser executes.

An enforced CSP that does not allow inline javascript, eval, or 3rd party sources is pretty solid and x-xss-protection would provide little benefit to most of your users.

If your users' browsers support CSP that is.

x-xss-protection has been supported by IE for many years. So in the case that someone is using IE < 12, CSP is useless where x-xss-protection can help.

So, yes. Both. Always. The internet would be a much safer world if every website deployed both.

I haven't dug in too far, but I haven't found a site that uses CSP but not x-xss-protection

for i in twitter.com vine.co github.com
do
   echo "$i"
   curl -Is "https://$i" | grep -iE "(x-xss-protection|content-security-policy)"
done

回答2:

Content Security Policy

The content security policy (CSP) is an additional layer of security added by some compatible browsers. With proper configuration, CSP helps to mitigate certain attacks such as XSS and script injection attacks or packet sniffing attacks. Technically, CSP is enabled if the header X-Content-Security-Policy is provided by the backend. Alternatively, It also can be enabled by the frontend. it is done by using the element as follows:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

CSP helps to stop XSS by whitelisting the executed javascript sources which also includes inline script and event-handling HTML attributes. The whitelisting is configured by the administator. The Admin can decides whether all the javascript links lead to the same origin, specific domain and what types of medias to expect from each domain. configuration examples:

Same Origin: Content-Security-Policy: default-src 'self'

Explicit Trusted domain: Content-Security-Policy: default-src 'self' *.trusted.com

X-XSS-PROTECTION

The goal of this header is to block XSS in the loaded page. The Admin got minimal configuration options such as reporting url, blocking page from loading... With proper CSP configuration, this header is not very effective. specially in modern browsers.