frame-ancestors doesn't fall back to default-src. So when we apply a
very restricted CSP we should make sure to set it to 'none' and not
leave it empty.

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

* Order the imports
* No leading slash on imports
* Empty line before namespace
* One line per import
* Empty after imports
* Emmpty line at bottom of file

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>

Signed-off-by: Morris Jobke <hey@morrisjobke.de>

As per https://twitter.com/we1x/status/842032709543333890

 a nice security hardening

Signed-off-by: Lukas Reschke <lukas@statuscode.ch>

CSP nonces are a feature available with CSP v2. Basically instead of saying "JS resources from the same domain are ok to be served" we now say "Ressources from everywhere are allowed as long as they add a `nonce` attribute to the script tag with the right nonce.

At the moment the nonce is basically just a `<?php p(base64_encode($_['requesttoken'])) ?>`, we have to decode the requesttoken since `:` is not an allowed value in the nonce. So if somebody does on their own include JS files (instead of using the `addScript` public API, they now must also include that attribute.)

IE does currently not implement CSP v2, thus there is a whitelist included that delivers the new CSP v2 policy to newer browsers. Check http://caniuse.com/#feat=contentsecuritypolicy2 for the current browser support list. An alternative approach would be to just add `'unsafe-inline'` as well as `'unsafe-inline'` is ignored by CSPv2 when a nonce is set. But this would make this security feature unusable at all in IE. Not worth it at the moment IMO.

Implementing this offers the following advantages:

1. **Security:** As we host resources from the same domain by design we don't have to worry about 'self' anymore being in the whitelist
2. **Performance:** We can move oc.js again to inline JS. This makes the loading way quicker as we don't have to load on every load of a new web page a blocking dynamically non-cached JavaScript file.

If you want to toy with CSP see also https://csp-evaluator.withgoogle.com/



Signed-off-by: Lukas Reschke <lukas@statuscode.ch>

* Move a-b to PSR-4

* Move c-d to PSR-4

* Move e+g to PSR-4

* Move h-l to PSR-4

* Move m-r to PSR-4

* Move s-u to PSR-4

* Move files/ to PSR-4

* Move remaining tests to PSR-4

* Remove Test\ from old autoloader

Allows to inject something into the default content policy. This is for
example useful when you're injecting Javascript code into a view belonging
to another controller and cannot modify its Content-Security-Policy itself.
Note that the adjustment is only applied to applications that use AppFramework
controllers.

To use this from your `app.php` use `\OC::$server->getContentSecurityPolicyManager()->addDefaultPolicy($policy)`,
$policy has to be of type `\OCP\AppFramework\Http\ContentSecurityPolicy`.

To test this add something like the following into an `app.php` of any enabled app:
```
$manager = \OC::$server->getContentSecurityPolicyManager();
$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFrameDomain('asdf');
$policy->addAllowedScriptDomain('yolo.com');

$policy->allowInlineScript(false);
$manager->addDefaultPolicy($policy);
$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFontDomain('yolo.com');
$manager->addDefaultPolicy($policy);

$policy = new \OCP\AppFramework\Http\ContentSecurityPolicy(false);
$policy->addAllowedFrameDomain('banana.com');
$manager->addDefaultPolicy($policy);
```

If you now open the files app the policy should be:

```
Content-Security-Policy:default-src 'none';script-src yolo.com 'self' 'unsafe-eval';style-src 'self' 'unsafe-inline';img-src 'self' data: blob:;font-src yolo.com 'self';connect-src 'self';media-src 'self';frame-src asdf banana.com 'self'
```

Fixes https://github.com/owncloud/core/issues/19438

For enhanced security it is important that there is also a way to disallow domains, including the default ones.

With this commit every method gets added a new "disallow" function.

This is required when working with stuff such as PDF.js in the files_pdfviewer application. Opt-in only.

Master change only because the stable CSP policies has a failback that allows nearly anything 

This change allows AppFramework applications to specify a custom CSP header for example when the default policy is too strict. Furthermore this allows us to partially migrate away from CSS and allowed eval() in our JavaScript components.

Legacy ownCloud components will still use the previous policy. Application developers can use this as following in their controllers:
```php
$response = new TemplateResponse('activity', 'list', []);
$cspHelper = new ContentSecurityPolicyHelper();
$cspHelper->addAllowedScriptDomain('www.owncloud.org');
$response->addHeader('Content-Security-Policy', $cspHelper->getPolicy());
return $response;
```

Fixes https://github.com/owncloud/core/issues/11857 which is a pre-requisite for https://github.com/owncloud/core/issues/13458 and https://github.com/owncloud/core/issues/11925