Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
samizdat
samizdat
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 32
    • Issues 32
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Michał "rysiek" Woźniak
  • samizdatsamizdat
  • Issues
  • #66

Closed
Open
Opened Sep 20, 2020 by Michał "rysiek" Woźniak@rysiek🔒Maintainer

Consider implementing means of detecting content deployed by an adversary

Currently Samizdat is unable to notice if, for whatever reason, content returned by any transport plugin (fetch, or any other that does not inherently provide end-to-end verification of content) is has been maliciously modified.

Scenario 1:

  1. Website is deployed with Samizdat in the current default configuration (fetch->cache->gun+ipfs).
  2. An adversary takes over the original domain, and deploys a new SSL certificate
  3. The adversary then deploys their own versions of some content (index.html, for example)
  4. When a user visits the site, fetch succeeds and the adversary-controlled index.html is displayed; alternative transports are not ever used for that file.

Scenario 2:

  1. Website is deployed with Samizdat configured to pull content from Google Drive as an alternative endpoint, in case original website is unavailable.
  2. An adversary gains access to the Google Drive folder by whatever means and modifies content.
  3. Then, the adversary blocks the original domain.
  4. Content modified by the adversary is now served to users.

This could be mitigated to some extent with some for of content signing, at least for HTML/CSS/JS, but at a cost of added complexity. Perhaps it could be implemented as an optional plugin, which would wrap any other plugin, and verify the content signature against a known public key of some sort. If the signature does not match (or is absent), throw an error.

The signature could be added as a comment in the last line of text-based files, for example. Headers won't work, since in case of most plugins there is no way to control the headers.

Edited Sep 23, 2020 by Michał "rysiek" Woźniak
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: rysiek/samizdat#66