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

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

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

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

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

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

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

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

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

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

Пояснения: задача противника (класс атак), вектор атаки, класс защиты, контрмера, отражающая атаку или изменяющая её вектор, рекомендация / вне контроля приложения. Стрелки в обозначениях классов внутри дерева — это ссылки на раскрытые деревья данных классов.

• Искажение информации на страницах сайта
  • Правка открытых страниц
    • Ограничение доступа на запись с помощью списков ACL
      • Повышение привилегий -->
        
  • Несанкционированный доступ к базе данных -->
    
  • Злоупотребление привилегиями (безосновательное удаление/модификация документов)
    • Репликация данных БД между независимыми серверами -->
      
    • Открытая модерация
      • Сивиллова атака
        • Репутационная система

• Раскрытие данных
  • Компрометация документов пользователями системы
    • Ограничение доступа на чтение с помощью списков ACL
      • Повышение привилегий -->
        
  • Несанкционированный доступ к базе данных -->

• Социальная инженерия
  • Имперсонация, дискредитация пользователей
    • Запрет регистрации похожих никнэймов

• Отказ в обслуживании
  • SYN-flood и т.п.
    • Брандмауэр, тюнинг сетевого стека
      
  • Уничтожение сервера
    • Репликация данных БД между независимыми серверами -->
      
  • Паразитные запросы
    • Кэширование данных
      
    • Flood-control (блокирование паразитирующих хостов)
      
    • Ограниченная балансировка нагрузки между зеркалами

• Повышение привилегий
  • Использование реквизитов доступа привилегированного пользователя
    • Захват идентификатора авторизованной сессии
      • Передача идентификатора только через cookie
        
      • Жёсткое ограничение продолжительности сессии
        
      • Привязка к IP
        
      • Cross-site scripting
        • Контроль и санитизация вывода
          
      • Перехват на канале связи
        • SSL
          
      • Несанкционированный доступ к базе данных -->
        • Хэширование идентификаторов сессий в БД
          
    • Компрометация пароля
      • Привязка к IP
        
      • Перехват на канале связи
        • SSL
          
        • Методы аутентификации без раскрытия секрета (по открытому ключу)
          
      • Несанкционированный доступ к базе данных -->
        • Хранение в БД хэшированных паролей с привязкой (salt)
          
      • Полный перебор
        • Контроль сложности паролей
          
        • Ограничение неудачных попыток
          
  • Эксплуатация бреши в приложении

• Несанкционированный доступ к базе данных
  • Клиентское заверение данных с помощью ЭЦП
    
  • Клиентское шифрование данных открытым ключом
    
  • Репликация данных БД между независимыми серверами -->
    
  • SQL-инъекция
    • Санитизация пользовательского ввода
      
  • Удалённый доступ к SQL-серверу / административной оболочке (phpMyAdmin) с помощью пароля БД
    • Запрет подключений к SQL-серверу от нелокальных хостов
      
    • Модульная реализация, границы доверия, предотвращение выхода критических данных (пароля БД и т.п.) за пределы доверенных зон
      
  • Физический доступ к серверу базы данных

• Несанкционированная модификация приложения
  • Запись на диск и в память, переопределение свойств и функций посредством выполнения произвольного кода через брешь в приложении
    • Компартментация кода, границы доверия, предотвращение выхода критических данных за пределы доверенных зон
      
    • Отсутствие процедур сериализации/десериализации объектов за пределами доверенных зон
      
    • Отсутствие вызовов eval() за пределами доверенных зон
      
  • Непосредственный доступ к ФС сервера приложения (SSH, физический доступ)

• Репликация данных БД между независимыми серверами
  • Модификация/компрометация реплицируемых данных на канале связи
    • Криптографический контроль целостности и конфиденциальности
      
  • Компрометация нешифрованных данных зеркалами
    
  • Отравление зеркал путём искажения БД мастер-сервера (мастер-сервер — сервер реплицирующий свою БД, независимо от того, централизованная это схема или децентрализованная с равноправными зеркалами)
    • Контроль целостности мастер-БД через запрос хэшей изменяемых записей или хэшей записей, предшествующих вставляемым, от зеркал и определение "правильности" по превалирующему значению хэшей
      • Несанкционированная модификация приложения -->
        
      • Сговор зеркал для искажения БД мастер-сервера
        
      • Искажение БД всех зеркал с целью блокирования консенсуса
        
  • Отравление зеркал целенаправленными действиями мастер-сервера

Мысли вслух

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

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

• Аутентификация и шифрование данных, передаваемых между зеркалами, ключами 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-ответе сервера (обосновать необходимость).