Минималистичный защищённый сервис обмена текстовой информацией07.10.2016 01:33

Представляю вам сайт bin.so — сервис для обмена текстовой информацией. Отличается от других функциями защиты данных:


  • Каждому загруженному тексту выделяется уникальный случайный URL
  • Если указать пароль, то информация шифруется прямо в браузере и на сервер сохраняется только зашифрованная версия данных. Для просмотра данных нужно ввести пароль, чтобы расшифровать в браузере данные, полученные с сервера.
  • Поисковым системам запрещено индексировать содержимое сайта
  • HTTPS везде

Шифрование данных в браузере обеспечено библиотекой SJCL. Данные шифруются AES алгоритмом в режиме SGM. Исходный код доступен на github. Серверная часть написана на python, веб-фреймворк Bottle, доступ к данным через peewee. База данных, по-умолчанию, sqlite.


Пользователи heroku могут запустить копию сайта в пару кликов мышки. Склонируйте репу на github. Через веб-интерфейс heroku создайте новое приложение и подключите github-репу.

Комментарии (17)

  • 7 октября 2016 в 00:21

    +4

    ↑

    ↓

    Немного, самую капельку, смущает webvisor от Яндекса, который отправляет в Яндекс все нажатия клавиш (включая контент и пароли), и адреса секретных страниц.

    • 7 октября 2016 в 00:49

      –1

      ↑

      ↓

      Идея хорошая, НО…
      Отличается от других функциями защиты данных

      bd40937534d7453d9c50d918241c3b81.png

      В свете этой новости: https://geektimes.ru/post/281188/

      Домен в зоне пиратского Сомали тоже не внушает.

      Всё это поправимо.

      • 7 октября 2016 в 01:03

        0

        ↑

        ↓

        По startcom ничего не скажу сейчас, надо разбираться.

        По поводу .so хочу услышать подробности, как доменное имя влияет на защиту данных.

        • 7 октября 2016 в 01:29

          0

          ↑

          ↓

          По startcom ничего не скажу сейчас, надо разбираться.

          Если сервис позиционируется действительно как защищённый, то сейчас бы надо принять хоть какие-нибудь действия, например, по временной замене сертификата до окончания «разборок» и чтения статьи выше.

          По доменному имени моё чисто субъективное мнение.

      • 7 октября 2016 в 01:17

        0

        ↑

        ↓

        Слышал звон, да не знает, где он

  • 7 октября 2016 в 00:34

    +1

    ↑

    ↓

    Каково происхождение файла /static/sjcl.js? Он существенно отличается от официальной минифицированной версии. Как получить вашу версию из официальной?

    • 7 октября 2016 в 00:38

      +1

      ↑

      ↓

      Файл был скачан с cdnjs.com. Конкретно, вот ссылка на файл: https://cdnjs.cloudflare.com/ajax/libs/sjcl/1.0.6/sjcl.min.js

  • 7 октября 2016 в 00:36

    +1

    ↑

    ↓

    Вы правы. Удалил код счётчика. Придётся парсить логи каким-нибудь вебаналайзером, чтобы хоть какую-то статсу иметь по посещаемости и источниках трафика.

  • 7 октября 2016 в 00:38

    +4

    ↑

    ↓

    Проблема шифрования в браузере в том, что я не могу быть уверен, что именно мне именно для моего браузера вы не отдадите чуточку модифицированные скрипты. И как эту проблему можно решить — непонятно.

    • 7 октября 2016 в 00:41

      +1

      ↑

      ↓

      Думаю — никак. Единственное решение, поднять копию сервиса на своём сервере.

      • 7 октября 2016 в 00:44

        0

        ↑

        ↓

        Или уйти от *.min.js, чтоб все было прозрачно

        • 7 октября 2016 в 00:48

          0

          ↑

          ↓

          Что вы имеете в виду? Грузить с github?

    • 7 октября 2016 в 00:45

      0

      ↑

      ↓

      Написать для браузера расширение, которое при каждом заходе будет ломиться на гитхаб, брать оттуда эталонные копии и сравнивать контрольные суммы :)

      • 7 октября 2016 в 01:30

        0

        ↑

        ↓

        Возможно будут интересны механизмы уже встроенные в последние версии браузеров, такие как Subresource Integrity, Content Security Policy и тд.

        • 7 октября 2016 в 01:32

          0

          ↑

          ↓

          Интегрити защищает от того, что CDN вместо ожидаемого jquery выдаст jquery с бонусом, собирающим пароли. Но интегрити не защищает от того, что владелец сайта выдаст вредоносный скрипт с правильным интегрити.

      • 7 октября 2016 в 01:31

        0

        ↑

        ↓

        Проблема в общем случае заключается в том, чтобы указать, откуда именно брать эталонные копии (читай — чью подпись на скрипте проверять). Если доверить самому сайту указывать ориджин для каждого подключенного ресурса — чем это будет отличаться от существующего подхода, где владелец может выдавать что угодно? А если нет — то как?

  • 7 октября 2016 в 00:52

    0

    ↑

    ↓

    Интересная идея. Т.е. вполне можно поднять в корпоративной сети и хранить копии документов.

© Habrahabr.ru