Otherwise an empty string is used indicating the cookie is only valid for those resources. This can lead to eunexpected behaviour.
Fixes https://github.com/owncloud/core/issues/19196
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)
Doing this in the PHP code is not the right approach for multiple reasons:
1. A bug in the PHP code prevents them from being added to the response.
2. They are only added when something is served via PHP and not in other cases (that makes for example the newest IE UXSS which is not yet patched by Microsoft exploitable on ownCloud)
3. Some headers such as the Strict-Transport-Security might require custom modifications by administrators. This was not possible before and lead to buggy situations.
This pull request moves those headers out of the PHP code and adds a security check to the admin settings performed via JS.
First stab at the StreamResponse, see #12988
The idea is to use an interface ICallbackResponse (I'm not 100% happy with the name yet, suggestions?) that allow the response to output things in its own way, for instance stream the file using readfile
Unittests are atm lacking, plan is to
check if a mock of ICallbackResponse will be used by calling its callback (also unhappy with this name) method
Usage is:
$response = new StreamResponse('path/to/file');
rename io to output, add additional methods and handle error and not modified cases when using StreamResponse
fix indention and uppercasing, also handle forbidden cases
fix indention
fix indention
no forbidden, figuring out if a file is really readable is too complicated to get to work across OSes and streams
remove useless import
remove useless import
fix intendation
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.
- VObject fixes for Sabre\VObject 3.3
- Remove VObject property workarounds
- Added prefetching for tags in sabre tags plugin
- Moved oc_properties logic to separate PropertyStorage backend (WIP)
- Fixed Sabre connector namespaces
- Improved files plugin to handle props on-demand
- Moved allowed props from server class to files plugin
- Fixed tags caching for files that are known to have no tags
(less queries)
- Added/fixed unit tests for Sabre FilesPlugin, TagsPlugin
- Replace OC\Connector\Sabre\Request with direct call to
httpRequest->setUrl()
- Fix exception detection in DAV client when using Sabre\DAV\Client
- Added setETag() on Node instead of using the static FileSystem
- Also preload tags/props when depth is infinity
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
Currently there is no AppFramework way to modify cookies, which makes it unusable for quite some use-cases or results in untestable code.
This PR adds some basic functionalities to add and invalidate cookies.
Usage:
```php
$response = new TemplateResponse(...);
$response->addCookie('foo', 'bar');
$response->invalidateCookie('foo');
$response->addCookie('bar', 'foo', new \DateTime('2015-01-01 00:00'));
```
Existing cookies can be accessed with the AppFramework using `$this->request->getCookie($name)`.
fix docstrings
adjust copyright date
another copyright date update
another header update
implement third headers argument, fix indention, fix docstrings
fix docstrings
Mitar
Robin Appelman
Thomas Müller
Lukas Reschke
Morris Jobke
Jörn Friedrich Dreyer
Robin McCorkell
Robin McCorkell
Joas Schilling
Jenkins for ownCloud
Bernhard Posselt
Vincent Petry
Georg Ehrke