When no cookies are sent it is not required to perform any check for the strict or lax cookie, it does not provide any significant security advantage.
It does however interfer with the Android client which requests thumbnails from the unofficial API at `/index.php/apps/files/api/v1/thumbnail/256/256/{filename}`. This endpoint expects the strict cookie to be existent to not leak the existence of files. The Android client authenticates against this endpoint using Basic Auth and without cookies in some cases at least. This will make these endpoints work again with such cases.
To test this issue the following cURL command once without the patch and once with:
> curl http://localhost/index.php/apps/files/api/v1/thumbnail/256/256/welcome.txt -u admin -v
Without the patch the request is redirected (which the client does not obey) and with the patch the preview is returned.
There are authentication backends such as Shibboleth that do send no Basic Auth credentials for DAV requests. This means that the ownCloud DAV backend would consider these requests coming from an untrusted source and require higher levels of security checks. (e.g. a CSRF check)
While an elegant solution would rely on authenticating via token (so that one can properly ensure that the request came indeed from a trusted client) this is a okay'ish workaround for this problem until we have something more reliable in the authentication code.
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.
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
