"Человек может иметь столько электронных личностей, на создание скольких ему хватит времени и сил".
- J. S. Donath, "Identity and Deception in the Virtual Community"

Типы хэндлеров документов (пространства имён)

• • Оптимизированная версия предыдущего варианта. Во-первых, каждая строка БД уже содержит хэш существенных полей данной строки (что избавляет зеркала от необходимости пересчитывать хэши при каждом коммите мастера, который, вероятно, просто пытается их заDoSить). Во-вторых, специальное поле (единственное для таблицы или для всей БД), содержащее XOR всех хэш-значений всех предыдущих коммитов и их счётчик. То есть получается так: когда пользователь вносить изменения в БД, сервер подсчитывает хэш существенных полей данной записи, вносить этот хэш в ту же строку БД, а затем XOR'ит его с текущим значением этого специального поля. В итоге, для полной синхронизации зеркалам нужно только обменяться значениями этого специального поля, сравнить его и счётчик, а полную сверку (описанную в п.2 предыдущего варианта, но с предрассчитанными хэшами) проводить только в случае расхождений.

Репутационная система

• • • Заверение операций клиента его открытым ключом, предоставление доказательств зеркалам
      
      • MITM-подмена ключа, впервые загружаемого пользователем, при его передаче от мастера к зеркалам
        
    • Приведённую выше MITM-подмену ключа на точке входа можно обобщить на любые впервые вводимые данные. Так, если правила аутентификации операций над объектом не закреплены мандатно, их добровольная установка может быть подделана мастер-сервером, и зеркала об этом никогда не узнают. (По-русски: предположим, требование о заверении всех операций с помощью ключей не установлено на сайте глобально; пользователь создаёт новый документ и включает это свойство локально для данной страницы. Но, независимо от желания пользователя, мастер-сервер не рассылает это обновление зеркалам, поэтому может и впредь любым образом модифицировать документ, бесконтрольно отправляя зеркалам злоумышленные редакции.) Решение пока неизвестно.

Антицензурный механизм

1. Мастер-сервер (где находится пользователь) извлекает из своей БД записи с n-i по n+i (где n — номер отредактированной пользователем записи, i — некоторое небольшое число), сериализует их и хэширует результат.
2. Мастер-сервер рассылает зеркалам параметры операции (n, i, тип выполняемого пользователем действия).
3. Зеркала повторяют операцию мастер-сервера со своими БД, заверяют полученные хэши своими закрытыми ключами и возвращают результат мастер-серверу.
4. Мастер подсчитывает "голоса" (каждое уникальное значение хэша) и сравнивает превалирующий хэш с собственным, полученным на этапе 1:
   • Если хэш мастера совпадает с большинством, он выполняет коммит зеркалам, передавая как введённые пользователем данные, так и все заверенные хэши, полученные от зеркал на этапе 3, и включая собственный. (Зеркала перед вводом данных в БД должны проверить правильность подсчётов мастера и отказать в коммите, если он лжёт.)
   • Если хэш мастера не совпадает с большинством, он запрашивает спорные записи у одного из зеркал с "правильным" хэшем, коммитит их в свою базу и перезапускает процесс с этапа 2.
   • Если все зеркала не имеют полного консенсуса относительно состояния базы, "меньшевики" по полученным от мастера заверенным хэшам также смогут определить, что у них что-то не так, и запросить "правильную" копию.

1. Как было отмечено, она не способна решить проблему с модификацией самой программы. В подобном случае одно из зеркал (или несколько) может поддерживать две базы: одну, используемую только для синхронизации, и другую, отцензурированную, данные из которой и отображаются пользователям. Описанный механизм является ограниченной мерой; адекватно устранить это ограничение можно лишь перенеся функции отрисовки и отображения данных на сторону клиента.
2. Скрытная модификация на одном из зеркал тех записей БД, которые обычно редко редактируются пользователями (или не редактируются совсем) и не имеют часто редактируемых соседей, так что подобное искажение может никогда не обнаружиться исполнением приведённого выше протокола. Решения:
   • Большое значение i, дабы каждым коммитом охватывать большее число соседних записей. Что, в свою очередь, означает дополнительную нагрузку на узлы при хэшировании большего объёма данных. В любом случае, само по себе такое решение не является полным.
   • Периодическое блокирование БД, хэширование всего содержимого и сравнение результатов между зеркалами. Собственные проблемы:
     1. Необходимость в синхронизации этого действа. В принципе, не слишком большая проблема (команду о выполнении полной проверки может рассылать один из узлов, получив которую, все начинают подготовку).
     2. Выявление спорных участков БД. Тоже решаемая задача: хэшировать блоки записей (скажем, по 100 строк), а затем — сам полученный набор хэшей. Такая схема позволит даже выполнять полную проверку в несколько этапов, дабы не останавливать работу сайта на длительный срок.
3. В принципе, ничто не мешает мастеру коммитить любые изменения, отравляя зеркала, покуда эта отрава будет синхронизирована между зеркалами (т.е. схема защищает только от скрытной модификации БД без ведома админа сервера, но не от целенаправленных действий админа). Решения:
   • Зеркала могут проверять вводимые данные против текущего состояния системы (например, мог ли данный пользователь отредактировать данную страницу, учитывая его привилегии и ACL документа), но такой механизм крайне легко обойти: просто лгать (выбрать пользователя с наивысшей репутацией/привилегиями и "править" документ от его имени).
   • Аутентификация пользовательского действия ключом PGP (это то, что зеркала могут объективно проверить). Хотя аутентификация большинства действий кажется тривиальной, более серьёзное размышление вырисовывает ряд попутных проблем:
     1. Атаки с повторной передачей, если заверять один только текст документа (как сейчас) без каких-либо метаданных. Решение:
        • Первые строчки документа должны содержать декларацию, логически привязывающую текст к данному применению (например, это может быть адрес документа и номер последней редакции). Такое доказательство зеркала могут принять.
     2. Трудности с аутентификацией действий, отличных от ввода простого контента, к примеру, изменений настроек или ACL документа. Решение:
        • В подобных случаях сервер может сериализовать действие пользователя (представить его в виде понятного пользователю текстового набора команд плюс значения счётчика для защиты от повторной передачи), которое последний и должен заверить цифровой подписью.
     3. Существует некоторый класс часто повторяемых действий, постоянная аутентификация которых может свести пользователя с ума. В частности, это работа с репутационной системой. (Следует учитывать, что это в немалой степени зависит от конкретного дизайна такой системы. Пока я рассматриваю идею с "плюсами" и "минусами", которые участники могут расставлять объектам системы, оказывая тем самым влияние на рейтинг владельцев этих объектов. Более подробно данный вопрос будет рассмотрен отдельно, поскольку требует учёта ряда "трудных" ситуаций, как то "правильную" оценку редакций документов.) Решение:
        • Не требовать аутентифицировать каждое такое действие, а только накапливать их в виде простых команд, которые пользователь в любой момент может заверить скопом. Такой подход требует особого внимания к пользовательскому интерфейсу, поскольку пользователь может покинуть сайт, не произведя заверение команд, и они будут просто потеряны (правда, можно и сохранять их в БД до следующего визита пользователя)...
     4. Главная сложность возникает на точке входа. Хотя аутентичность последующих изменений БД можно проконтролировать с помощью описанных мер, у зеркал не может быть гарантии, что первая загрузка открытого ключа пользователя в действительности выполнена им самим, и ключ принадлежит пользователю. Ничто не мешает мастеру MITM'ить ключи всех пользователей. Решения:
        • Загрузив ключ на мастер, пользователь может обойти зеркала и проверить, что на них также находится его ключ. Но как он в случае подлога докажет зеркалам, что это и впрямь не его ключ?
        • На странице загрузки ключа помещать несколько самостоятельных веб-форм, каждая выполняющая POST-запрос на соответствующее зеркало. Дёшево и сердито, зато работает.
     Не окажется ли, что способы решения вышеназванных проблем превратят всю систему в мертворождённого ребёнка, сделав её практически непригодной к использованию? С другой стороны, множество механизмов безопасности, в том числе и аутентификация пользовательских действий, могут быть опциональны и применяться лишь на ограниченном наборе документов (или быть локализованы по иному признаку).

• Искажение информации на страницах сайта
  
  • Правка открытых страниц
    
    • Ограничение доступа на запись с помощью списков ACL
      
      • Повышение привилегий -->
        
  • Несанкционированный доступ к базе данных -->
    
  • Злоупотребление привилегиями (безосновательное удаление/модификация документов)
    
    • Репликация данных БД между независимыми серверами -->
      
    • Открытая модерация
      
      • Сивиллова атака
        
        • Репутационная система
          
• Раскрытие данных
  
  • Компрометация документов пользователями системы
    
    • Ограничение доступа на чтение с помощью списков ACL
      
      • Повышение привилегий -->
        
  • Несанкционированный доступ к базе данных -->
    
• Социальная инженерия
  
  • Имперсонация, дискредитация пользователей
    
    • Запрет регистрации похожих никнэймов
      
• Отказ в обслуживании
  
  • SYN-flood и т.п.
    
    • Брандмауэр, тюнинг сетевого стека
      
  • Уничтожение сервера
    
    • Репликация данных БД между независимыми серверами -->
      
  • Паразитные запросы
    
    • Кэширование данных
      
    • Flood-control (блокирование паразитирующих хостов)
      
    • Ограниченная балансировка нагрузки между зеркалами
      
• Повышение привилегий
  
  • Использование реквизитов доступа привилегированного пользователя
    
    • Захват идентификатора авторизованной сессии
      
      • Передача идентификатора только через cookie
        
      • Жёсткое ограничение продолжительности сессии
        
      • Привязка к IP
        
      • Cross-site scripting
        
        • Контроль и санитизация вывода
          
      • Перехват на канале связи
        
        • SSL
          
      • Несанкционированный доступ к базе данных -->
        
        • Хэширование идентификаторов сессий в БД
          
    • Компрометация пароля
      
      • Привязка к IP
        
      • Перехват на канале связи
        
        • SSL
          
        • Методы аутентификации без раскрытия секрета (по открытому ключу)
          
      • Несанкционированный доступ к базе данных -->
        
        • Хранение в БД хэшированных паролей с привязкой (salt)
          
      • Полный перебор
        
        • Контроль сложности паролей
          
        • Ограничение неудачных попыток
          
  • Эксплуатация бреши в приложении
    
• Несанкционированный доступ к базе данных
  
  • Клиентское заверение данных с помощью ЭЦП
    
  • Клиентское шифрование данных открытым ключом
    
  • Репликация данных БД между независимыми серверами -->
    
  • SQL-инъекция
    
    • Санитизация пользовательского ввода
      
  • Удалённый доступ к SQL-серверу / административной оболочке (phpMyAdmin) с помощью пароля БД
    
    • Запрет подключений к SQL-серверу от нелокальных хостов
      
    • Модульная реализация, границы доверия, предотвращение выхода критических данных (пароля БД и т.п.) за пределы доверенных зон
      
  • Физический доступ к серверу базы данных
    
• Несанкционированная модификация приложения
  
  • Запись на диск и в память, переопределение свойств и функций посредством выполнения произвольного кода через брешь в приложении
    
    • Компартментация кода, границы доверия, предотвращение выхода критических данных за пределы доверенных зон
      
    • Отсутствие процедур сериализации/десериализации объектов за пределами доверенных зон
      
    • Отсутствие вызовов eval() за пределами доверенных зон
      
  • Непосредственный доступ к ФС сервера приложения (SSH, физический доступ)
    
• Репликация данных БД между независимыми серверами
  
  • Модификация/компрометация реплицируемых данных на канале связи
    
    • Криптографический контроль целостности и конфиденциальности
      
  • Компрометация нешифрованных данных зеркалами
    
  • Отравление зеркал путём искажения БД мастер-сервера (мастер-сервер — сервер реплицирующий свою БД, независимо от того, централизованная это схема или децентрализованная с равноправными зеркалами)
    
    • Контроль целостности мастер-БД через запрос хэшей изменяемых записей или хэшей записей, предшествующих вставляемым, от зеркал и определение "правильности" по превалирующему значению хэшей
      
      • Несанкционированная модификация приложения -->
        
      • Сговор зеркал для искажения БД мастер-сервера
        
      • Искажение БД всех зеркал с целью блокирования консенсуса
        
  • Отравление зеркал целенаправленными действиями мастер-сервера

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

• Базовые условия:
  • Wiki, свободное участие посетителей в развитии материалов.
  • Спорность, неоднозначность многих материалов.
  • Враждебность окружения.
• Регулярный веб-хостинг.
  • Стандартное окружение и среда исполнения: Linux/BSD, Apache, CGI, Python, MySQL.
  • Отсутствие контроля над средой исполнения и хранилищем данных.
• Скрытый сервис сети Tor.
  • Высокая вероятность отказа, пропадания ресурса без объявления причин.
  • Крайне низкая производительность сетевого соединения.
• Сайт правозащитной направленности.
  • Риск навязывания цензуры администрации сайта; цензурирование материалов без ведома администрации.
  • Принуждение администрации к раскрытию информации; правовое и внеправовое давление.

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

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

• • domain.com/pagename:[type]:[handler][@lang]. Не вызовет проблем с одноимёнными страницами, поскольку определения типа и хэндлера явно отделены от URL нетипичным символом. Определение языка должно иметь уникальный разделитель, дабы не создавать двусмысленности при опущенных определениях типа и хэндлера. Минус: не слишком элегантный URL с кучей служебных символов (а ведь дальше могут следовать параметры GET-запроса). Приоритетный вариант, если не придумается что-нибудь лучше.

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

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

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