Skip to content

Commit e66defb

Browse files
committed
docs: Update to reflect change in security modal.
1 parent f7e58a6 commit e66defb

File tree

2 files changed

+5
-20
lines changed

2 files changed

+5
-20
lines changed

docs/roadmap.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -176,9 +176,9 @@ of its size, it takes work to keep it that way.
176176

177177
* [Add support for 2-factor authentication on all
178178
platforms](https://github.com/zulip/zulip/pull/1747)
179-
* [Add support for stronger security controls for uploaded files (The
179+
* <strike>[Add support for stronger security controls for uploaded files (The
180180
LOCAL_UPLOADS_DIR file uploads backend only supports world-readable
181-
uploads)](https://github.com/zulip/zulip/issues/320)
181+
uploads)](https://github.com/zulip/zulip/issues/320)</strike>
182182
* [Fix requirement to set a password when creating account via
183183
Google](https://github.com/zulip/zulip/issues/1633)
184184
* [Add a retention policy feature that automatically deletes old

docs/security-model.md

Lines changed: 3 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -184,24 +184,9 @@ your organization.
184184
* Zulip supports user-uploaded files; ideally they should be hosted
185185
from a separate domain from the main Zulip server to protect against
186186
various same-domain attacks (e.g. zulip-user-content.example.com)
187-
using the S3 integration.
188-
189-
The URLs of user-uploaded files are secret; if you are using the
190-
"local file upload" integration, anyone with the URL of an uploaded
191-
file can access the file. This means the local uploads integration
192-
is vulnerable to a subtle attack where if a user clicks on a link in
193-
a secret .PDF or .HTML file that had been uploaded to Zulip, access
194-
to the file might be leaked to the other server via the Referrer
195-
header (see [the "Uploads world readable" issue on
196-
GitHub](https://github.com/zulip/zulip/issues/320)).
197-
198-
The Zulip S3 file upload integration is relatively safe against that
199-
attack, because the URLs of files presented to users don't host the
200-
content. Instead, the S3 integration checks the user has a valid
201-
Zulip session in the relevant realm, and if so then redirects the
202-
browser to a one-time S3 URL that expires a short time later.
203-
Keeping the URL secret is still important to avoid other users in
204-
the Zulip realm from being able to access the file.
187+
using the S3 integration. The uploaded files could be viewed by only
188+
those users who have access to them. Simple possession of a URL to
189+
the uploaded file doesn't qualify as a right to view such a file.
205190

206191
* Zulip supports using the Camo image proxy to proxy content like
207192
inline image previews that can be inserted into the Zulip message

0 commit comments

Comments
 (0)