* 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
This adds a new CSRF manager for unit testing purposes, it's interface is based upon https://github.com/symfony/security-csrf. Due to some of our required custom changes it is however not possible to use the Symfony component directly.
While BREACH requires the following three factors to be effectively exploitable we should add another mitigation:
1. Application must support HTTP compression
2. Response most reflect user-controlled input
3. Response should contain sensitive data
Especially part 2 is with ownCloud not really given since user-input is usually only echoed if a CSRF token has been passed.
To reduce the risk even further it is however sensible to encrypt the CSRF token with a shared secret. Since this will change on every request an attack such as BREACH is not feasible anymore against the CSRF token at least.
There are cases where no trusted host is specified such as when installing the instance, this lead to an undefined offset warning in the log right after installing. (when another domain than localhost or 127.0.0.1 was used)
X-Forwarded-Proto contains a list of protocols if ownCloud is behind multiple reverse proxies.
This is a revival of https://github.com/owncloud/core/pull/11157 using the new IRequest public API.
This changeset removes the static class `OC_Request` and moves the functions either into `IRequest` which is accessible via `\OC::$server::->getRequest()` or into a separated `TrustedDomainHelper` class for some helper methods which should not be publicly exposed.
This changes only internal methods and nothing on the public API. Some public functions in `util.php` have been deprecated though in favour of the new non-static functions.
Unfortunately some part of this code uses things like `__DIR__` and thus is not completely unit-testable. Where tests where possible they ahve been added though.
Fixes https://github.com/owncloud/core/issues/13976 which was requested in https://github.com/owncloud/core/pull/13973#issuecomment-73492969
When `mod_unique_id` is enabled the ID generated by it will be used for logging. This allows for correlation of the Apache logs and the ownCloud logs.
Testplan:
- [ ] When `mod_unique_id` is enabled the request ID equals the one generated by `mod_unique_id`.
- [ ] When `mod_unique_id` is not available the request ID is a 20 character long random string
- [ ] The generated Id is stable over the lifespan of one request
Changeset looks a little bit larger since I had to adjust every unit test using the HTTP\Request class for proper DI.
Fixes https://github.com/owncloud/core/issues/13366
