Я надеюсь, вы помните, что этот блог является площадкой для обкатки всяких новых и интересных¹ технологий. И некоторое время назад я пришел к мысли, что тех архитектурных решений, которые я заложил в первую версию блога, мне не хватает. Что из этого следует? Конечно, нужно сделать новый сайт. Первая версия делалась с целью получить приемлемый результат минимальными усилиями, новую я хочу с делать с учетом ошибок первой и лучшего понимания общей идеологии. И именно к этому я приступил пару недель назад.

Очень постараюсь не лениться и представлять своего рода отчеты о проделанной работе. Собственно, следить за разработкой (если есть такое желание) можно на GitHub. Для этого там была создана ветка dev.

В ближайших планах рассказать вам об интернационализации (i18n), сериализации/десериализации в json и создании снаплетов. Что из этого интереснее? Еще есть хорошая тема «Template Haskell, или что я был бы не прочь увидеть в других языках.» В любом случае, если вам хочется узнать подробнее, а я всё никак не разрожусь текстом, — не стесняйтесь указать на это в комментариях или письме.

Забыл сказать, что пока переделка касается только серверной части. Javascript останется таким, как есть, разве что адаптируется под новые возможности.

Пришла хорошая новость от бойцов команды Snap Framework — новая версия их фреймворка. Плюс у них обновился и движок шаблонов Heist. Вернее даже не так. Вышел новый Heist, а Snap обновили, чтобы поддержать нововведения Heist. Как утверждают разработчики, скорость работы шаблонизатора возросла в какое-то невероятное число раз: от 700 на простых шаблонах и до 3000+ на сложных. Причем это достигается за счет более сложных алгоритмов прекомпиляции и отказа от некоторых динамических структур.

Думаю, в скором времени я вплотную засяду за портирование сайта на обновленный фреймворк: я же хочу, чтобы он работал еще быстрее. А несовместимых вещей обещают много…

Как вы, должно быть, знаете, хранить пользовательские данные на клиентской стороне плохо: их ведь может подделать злостный хакер. Но сегодня я вам расскажу, как можно безопасно хранить сессионные данные, не волнуясь за их сохранность. Расскажу на примере Snap Framework, на котором и написан этот блог.

Суть метода — шифрование (кто бы мог подумать). Snap для своих сессий использует библиотеку Web.ClientSession, а поэтому что и как обрабатывается можно смело подсмотреть в документации:

• Шифруем данные куки с помощью AES в режиме CTR. Это позволяет хранить важные данные на стороне клиента, не беспокоясь о том, что их кто-нибудь украдет.
• Подписываем зашифрованные данные с помощью Skein-MAC-512-256. Кроме определения потенциальных ошибок в хранении и передачи данных (целостность), MAC предотвращает изменения данных и подтверждает, что они действительно были сгенерированны этим сервером (подлинность).
• Кодируем результат с помощью Base64, таким образом избавляемся от различных непечатных символов и отдаем браузеру простую строку.

Изучая всякие википедии о AES, я не особо понял, какие преимущества нам даст режим CTR в плане безопасности, но судя по описанию коммитов к библиотеке в этом режиме результат получается чуть более компактным и сам алгоритм чуть проще реализовывается. Про любой другой язык я могу сказать, что почти наверняка есть библиотека, которая уже реализует этот алгоритм за вас, так что сильно думать не придется.

Skein — это просто хороший алгоритм хеширования. К сожалению, он не победил в конкуре на замену SHA-2, и название SHA-3 получил другой алгоритм. Поэтому самое время заменить Skein на новоявленный SHA-3 — Keccak.

Ну и напоследок несколько мыслей. Во-первых, этот метод хранения несколько надежнее традиционных, т.к. никакой форс-мажор на сервере не позволит данным потеряться. А если что-нибудь произойдет со стороны клиента и кука исчезнет, то на сервере у нас не останется никаких мусорных данных об уже не существующей сессии. Во-вторых, таким образом не получится хранить большие объемы данных, т.к. размер куки ограничен, да и передача каждый раз пары десятков-сотен килобайт вполне может увеличить нагрузку на сервер. В-третьих, увести сессию можно точно так же, как и обыкновенную, поэтому увеличения безопасности тут не будет.

В общем, идея имеет право на жизнь. Особенно на небольших, как в моем случае, объемах хранимых данных. Лично я храню только одно поле: является ли текущий пользователь админом или нет.

Хозяйке на заметку: чтобы вашу сессию нельзя было увести с помощью JavaScript, добавьте в заголовок Set-Cookie параметр HttpOnly. Куки с таким параметром не появляются в document.cookie.

Осталась одна загадка, связанная с моим сайтом. Кука _session передается как сессионная и должна удаляться с закрытием браузера. Так и происходит в Opera, но не Google Chrome и Firefox. Может есть какая-то стандартизированная или неофициальная фича, которая не дает сессионным кукам удалиться?