id: Гость   вход   регистрация
текущее время 11:39 19/01/2021
Владелец: SATtva редакция от 26/01/2008 00:47 (автор: SATtva) Печать
Категории: софт, инфобезопасность, безопасная разработка, исходные тексты, разное, сообщество
http://www.pgpru.com/Разработки/Движок/ПереработкаПрограммы
создать
просмотр
редакции
ссылки

Это старая редакция страницы Разработки / Движок / Переработка Программы за 26/01/2008 00:47.


Переработка и укрепление программы


Как было отмечено расширение кода WackoWiki себя исчерпало, и программа будет переписана с нуля с упором на аспекты безопасности. На этой странице можно будет следить за ходом разработки и обсуждать какие-то дизайнерские решения.


Комментарии, замечания и корректировки горячо приветствуются.

Оглавление документа:

Формализация

Профиль использования


  • Базовые условия:
    • Wiki, свободное участие посетителей в развитии материалов.
    • Спорность, неоднозначность многих материалов.
    • Враждебность окружения.

  • Регулярный веб-хостинг.
    • Стандартное окружение и среда исполнения: Linux/BSD, Apache, CGI, Python, MySQL.
    • Отсутствие контроля над средой исполнения и хранилищем данных.

  • Скрытый сервис сети Tor.
    • Высокая вероятность отказа, пропадания ресурса без объявления причин.
    • Крайне низкая производительность сетевого соединения.

  • Сайт правозащитной направленности.
    • Риск навязывания цензуры администрации сайта; цензурирование материалов без ведома администрации.
    • Принуждение администрации к раскрытию информации; правовое и внеправовое давление.

Модель угрозы

Мысли вслух

Имеет ли смысл встроенная функция зеркалирования данных между несколькими сайтами или её стоит решать сторонними средствами?


Если встраивать функцию, то:

  • Аутентификация и шифрование данных, передаваемых между зеркалами, ключами OpenPGP. Что гарантирует защиту на канале связи, но не способствует защите от захвата хоста и отравления зеркал.

Типы хэндлеров документов


  • WackoWiki имеет характерную концепцию хэндлеров — инструментов работы с документом. Примеры хэндлеров — это show (просмотр страницы), edit (её правка), acls (настройка прав доступа). Достаточно дописать имя хэндлера в конец URL, чтобы получить к нему доступ. Хэндлеры позволяют достаточно эффективно разбить функционал на независимые модули, элегантно вызываемые через URL без всей GET-галиматьи типа pagename?handler=edit.

  • Вторая концепция, не получившая развития в оригинальной Ваке — это типы хэндлеров. В Ваке определён только один — page, в который и свалены все хэндлеры для работы с документом. Хотя данную идею легко расширить, определив типы, например, для опросов, административных модулей, комментариев, существенно унифицируя систему и делая её легко расширяемой: чтобы добавить функционал, достаточно определить новое пространство имён, или "класс", если угодно (в виде типа хэндлеров), и "методы" такого "класса" (в виде самих хэндлеров).

  • Первая проблема заключается в способе передачи типа хэндлера через URL запроса в систему. Варианты:
    • domain.com/[type]/pagename/[handler][:lang]. Ломает все существующие ссылки. Решения: 1) переписать все ссылки при конверсии базы (ссылки с внешних ресурсов всё равно останутся битыми), 2) принять отсутствие типа за тип page. Более глобальная проблема этого подхода в том, что подобное резервирование имён может в дальнейшем выйти боком при последующих расширениях, если новый тип foobar станет конфликтовать с документом foobar на каком-то сайте.
    • domain.com/pagename/[type]/[handler][:lang]. Особых сложностей это не создаст, хотя вариант с переопределением одноимённых пользовательских страниц остаётся возможен (пусть и не станет переопределять целые кластеры). Как и сейчас, по умолчанию можно принимать page/show. Учитывая, что и другие типы должны по идее иметь свои хэндлеры show, то он может быть глобальным умолчанием. А так получаем, к примеру, site.com/ВыПересталиБитьЖенуПоУтрам/poll/results, что откроет нам результаты данного опроса.
    • domain.com/pagename:[type]:[handler][@lang]. Не вызовет проблем с одноимёнными страницами, поскольку определения типа и хэндлера явно отделены от URL нетипичным символом. Определение языка должно иметь уникальный разделитель, дабы не создавать двусмысленности при опущенных определениях типа и хэндлера. Минус: не слишком элегантный URL с кучей служебных символов (а ведь дальше могут следовать параметры GET-запроса). Приоритетный вариант, если не придумается что-нибудь лучше.

  • Вторая проблема — это способ распределения пространств имён в базе данных. Сейчас все страницы лежат в одной таблице pages, там же есть доставшееся по наследству поле handler, заполненное везде константой page. Редакции находятся в таблице revisions, имеющей почти идентичную структуру. Варианты:
    • оставить, как есть. Документы из всех пространств лежат в одной таблице. Уникальный ключ каждой записи — это триплет name:type:lang. Плюсы: 1) единообразие и лёгкая расширяемость: опять же, добавление функционала не потребует никаких особых действий, кроме написания/установки модуля; 2) возможность хранить редакции всех документов независимо от типа в одном месте; 3) управление записями таблицы может осуществляться одним базовым набором инструментов. Минусы: 1) таблица может стать о-о-о-очень большой; 2) документы определённых типов могут потребовать особых полей, недоступных в таблице.
    • для каждого типа выделить отдельную одноимённую таблицу. Плюсы: 1) высокая оптимизация каждой таблицы под конкретные данные, учитывая специфику документов; 2) распределение объёма базы по набору таблиц, что упрощает операции резервирования. Минусы: 1) расширение функционала затруднено — требуется создавать новые таблицы и поддерживать их структуру в актуальном виде; 2) хранение редакций затруднено (придётся создавать таблицы редакций и для типов документов) или невозможно; 3) в каких-то случаях для управления записями могут потребоваться специальные программные инструменты; 4) степень дублирования структуры и данных в действительности может оказаться довольно высока.
    • альтернативы? первый вариант на мой взгляд выигрышней, несмотря на минусы, которые можно сгладить или обойти.

Предотвращение race conditions. Атомарные операции


  • Логические блокировки (мютексы) записей БД при мультитранзакционных операциях.
    • Особенно важное условие при действующей структуре БД (пока спасала лишь невысокая посещаемость сайта), но принципиально не удастся избежать всех возможных узких мест даже с переработанной структурой.
    • Возможно ли обеспечить блокировку лишь средствами БД (выделив под размещение мютексов специальную таблицу)? Похоже, что LOCK TABLES в MySQL исключит появление race'а уже в установке/проверке самих мютексов разными потоками. С другой стороны, при таком подходе вообще отпадает потребность в самодельных средствах блокировки. Требует дальнейшего изучения. Важно соблюсти баланс производительности и атомарности операций.

Клиентское приложение (плагин Firefox?) для автоматического зашифрования/расшифрования особо важных документов


Реализация на втором этапе (отдалённая перспектива). Характеристики:

  • Безопасный IPC-интерфейс для связи с процессом GnuPG (реализован в Enigmail).
  • Автоматическая обработка пересылаемых POST-данных (реализовано в Enigform).
  • Шифрование передаваемых данных (реализовано в FireGPG).
  • Policy-centric-управление посредством подписанных хидеров в HTTP-ответе сервера (обосновать необходимость).