mirror/archivebox
1
0
Fork 0
mirror of https://github.com/pirate/ArchiveBox.git synced 2025-08-22 22:25:24 +02:00
Code Issues Releases Wiki Activity

Updated Publishing Your Archive (markdown)

Nick Sweeting
2024-05-03 19:02:14 -07:00
parent 21fe946b8e
commit a7099684dd
1 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
Publishing-Your-Archive.md

@@ -66,14 +66,19 @@ Urls look like: `https://demo.archivebox.io/archive/1493350273/en.wikipedia.org/
## Security Concerns ## Security Concerns
> [!CAUTION] > [!CAUTION]
> Re-hosting untrusted archived web content on a public domain can potentially compromise *all apps hosted on that domain** (including other subdomains)! If a logged-in user happens to visit an archived page with malicious Javascript embedded, it can hijack any cookies on the domain and pretend to be them. > Re-hosting untrusted archived web content on a public domain can potentially compromise *all apps hosted on that domain* (including other subdomains)!
Make sure you thoroughly understand the dangers of [hosting untrusted HTML/JS/CSS that may be captured during archiving](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy), and how viewing it can enable [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery) across all apps on the same domain. Make sure you thoroughly understand the dangers of [hosting untrusted HTML/JS/CSS that may be captured during archiving](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy), and how viewing it can enable [CSRF attacks](https://en.wikipedia.org/wiki/Cross-site_request_forgery) across all apps on the same domain. If a logged-in user happens to visit an archived page with malicious Javascript embedded, it can hijack any cookies on the domain and pretend to be them.
You must put ArchiveBox a domain of its own (or at least subdomain), it should not be shared with any other applications in order to mitigate potential damage of leaked cookies, CORS, and CSRF attack.
(This is why we don't support serving ArchiveBox from a subdirectory on a shared domain like `myapps.example.com/archivebox/`) (This is why we don't support serving ArchiveBox from a subdirectory on a shared domain like `myapps.example.com/archivebox/`)
The industry standard approach is to use a separate domain for untrusted content, for example Github uses `githubusercontent.com` and Google uses `googleusercontent.com` for all user-uploaded files. If hosting ArchiveBox publicly, do the same and keep it on an isolated domain in order to mitigate potential damage of leaked cookies, CORS, and CSRF attack.
To protect the Admin dashboard, it's also recommended to serve all content under `/archive/` on a separate domain from `/admin/`. We do this on our servers using a simple redirect rule in nginx/cloudflare like so:
- https://demo.archivebox.io: only serves `/`, redirects `/archive/*` to `demo-static.`
- https://demo-static.archivebox.io: only serves `/archive/`, redirects everything else to `demo.`
More info: More info:
- https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview - https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview
- https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview#publishing - https://github.com/ArchiveBox/ArchiveBox/wiki/Security-Overview#publishing