security: add SECURITY.md
This commit is contained in:
+118
@@ -0,0 +1,118 @@
|
|||||||
|
# Security Policy
|
||||||
|
|
||||||
|
## Reporting a Vulnerability
|
||||||
|
|
||||||
|
Please report security issues through **GitHub Security Advisories** — the
|
||||||
|
private-disclosure channel integrated with this repository:
|
||||||
|
|
||||||
|
<https://github.com/EdouardVanbelle/OxiCloud/security/advisories/new>
|
||||||
|
|
||||||
|
If GitHub isn't a viable channel for you (organisational policy, no GH
|
||||||
|
account, etc.), email a maintainer directly at
|
||||||
|
<opensource+security@edouard.vanbelle.fr>. Please include the word `security`
|
||||||
|
in the subject line so it routes ahead of general project mail.
|
||||||
|
|
||||||
|
**Please do NOT open public GitHub issues for security vulnerabilities.**
|
||||||
|
A public issue makes the finding available to attackers before the fix
|
||||||
|
ships, which is exactly what we're trying to avoid.
|
||||||
|
|
||||||
|
## What to include
|
||||||
|
|
||||||
|
A short, specific report is far more useful than a long generic one. If
|
||||||
|
you can share:
|
||||||
|
|
||||||
|
- A concise description of the issue and its impact
|
||||||
|
- Steps to reproduce, or a proof-of-concept if one exists
|
||||||
|
- Affected component (REST API, WebDAV, NextCloud DAV, CalDAV, CardDAV,
|
||||||
|
WOPI, auth, frontend, …)
|
||||||
|
- Affected version or commit hash
|
||||||
|
- Any remediation you've already identified
|
||||||
|
|
||||||
|
Both executed exploits AND code-review findings are welcome — mention
|
||||||
|
which one it is (e.g. "I found this pattern in the source but couldn't
|
||||||
|
build the service to verify runtime") so we know what to expect.
|
||||||
|
|
||||||
|
If you're not sure whether something is a vulnerability, err on the
|
||||||
|
side of reporting; we'd rather triage a false positive than miss a
|
||||||
|
real issue.
|
||||||
|
|
||||||
|
## Response expectations
|
||||||
|
|
||||||
|
OxiCloud is maintained by a small volunteer team. Realistic timelines:
|
||||||
|
|
||||||
|
- **Acknowledgement:** within 5 business days
|
||||||
|
- **Initial triage and severity assessment:** within 14 days
|
||||||
|
- **Fix on `main`:** timeline depends on complexity, communicated during
|
||||||
|
triage
|
||||||
|
- **Public disclosure:** coordinated with the reporter, typically after
|
||||||
|
the fix has been available on `main` long enough for downstream users
|
||||||
|
to update
|
||||||
|
|
||||||
|
If you don't hear back within 5 business days, please ping the private
|
||||||
|
advisory or resend the email — reports occasionally get missed.
|
||||||
|
|
||||||
|
## Scope
|
||||||
|
|
||||||
|
**In scope:**
|
||||||
|
|
||||||
|
- Server (`src/`) — anything reachable via the HTTP surface
|
||||||
|
(REST API, WebDAV, NextCloud DAV, CalDAV, CardDAV, WOPI) or via
|
||||||
|
authentication / authorization / session management
|
||||||
|
- Frontend (`frontend/`) — client-side issues (XSS, CSRF gaps,
|
||||||
|
insecure client-side storage, DOM sinks)
|
||||||
|
- Build artifacts and release tarballs — supply-chain and packaging
|
||||||
|
integrity
|
||||||
|
- The migration and background-job surfaces — anything an authenticated
|
||||||
|
user or admin can trigger
|
||||||
|
|
||||||
|
**Out of scope** (please don't spend your time on these):
|
||||||
|
|
||||||
|
- Missing security headers on non-authenticated public endpoints
|
||||||
|
(already tracked)
|
||||||
|
- Rate-limit tuning suggestions
|
||||||
|
- Denial-of-service via resource exhaustion at scales beyond the
|
||||||
|
documented deployment guidance
|
||||||
|
- Findings that require attacker-controlled physical or root access to
|
||||||
|
the server host
|
||||||
|
- Vulnerabilities in third-party dependencies that don't have a
|
||||||
|
reachable path from OxiCloud code (report those upstream)
|
||||||
|
|
||||||
|
## Safe-harbor
|
||||||
|
|
||||||
|
We won't pursue legal action against researchers acting in good faith
|
||||||
|
under this policy — that means:
|
||||||
|
|
||||||
|
- Not accessing or modifying data belonging to other users beyond the
|
||||||
|
minimum needed to demonstrate the issue
|
||||||
|
- Not degrading service for others (no volumetric testing without
|
||||||
|
coordination)
|
||||||
|
- Reporting the issue privately before any public disclosure
|
||||||
|
- Giving us reasonable time to fix before publishing
|
||||||
|
|
||||||
|
Testing against your own self-hosted instance is always fine. Testing
|
||||||
|
against a third-party OxiCloud deployment requires explicit permission
|
||||||
|
from that deployment's operator.
|
||||||
|
|
||||||
|
## Credit
|
||||||
|
|
||||||
|
We're happy to credit reporters in the fix commit, release notes, and
|
||||||
|
this file's history. Tell us your preferred name or handle when you
|
||||||
|
report, or say if you'd rather stay anonymous.
|
||||||
|
|
||||||
|
## Prior reports
|
||||||
|
|
||||||
|
Coordinated disclosures we've received and resolved:
|
||||||
|
|
||||||
|
- **2026-09-05** — Timing side-channel in WebDAV lock-token comparison
|
||||||
|
(`evaluate_if_header` in `src/interfaces/api/handlers/webdav_handler.rs`
|
||||||
|
used plain `==` on state-tokens, byte-wise with early exit). Fixed by
|
||||||
|
routing lock-token comparisons through a `subtle::ConstantTimeEq`
|
||||||
|
helper. Practical exploitability was marginal (ns-scale signal buried
|
||||||
|
in ms-scale network jitter, ~5×10⁸ samples required within the lock's
|
||||||
|
default 60 s–1 h lifetime), but the fix is small and matches the
|
||||||
|
constant-time-compare hygiene applied elsewhere in the codebase.
|
||||||
|
Reported by **Abdurazzoqov Javohir**
|
||||||
|
([@abdurazzoqovjavohir700-dev](https://github.com/abdurazzoqovjavohir700-dev))
|
||||||
|
via responsible disclosure; fix landed in
|
||||||
|
[PR #712](https://github.com/AtalayaLabs/OxiCloud/pull/712). Thanks
|
||||||
|
for the clear report and the specific remediation suggestion.
|
||||||
Reference in New Issue
Block a user