Леонид Каганов: дневник

Думаю, где-то в ноябре всерьез взяться за проект, чтобы к Новому году наконец открыть binoniq.net как публичный дневниковый сервис, и пусть уже начнет жить. А то этот долгострой мне уже самому надоел. Размышляю над концепцией безопасности.

Как известно, концепций безопасности три. Грубо говоря:

1. «ПНХ — Пожалуйста не хулиганьте!» Это концепция Виндоус, когда предполагается, что почти все люди честные, а если кто-то проник на территорию нечестный, то его пусть найдет специальный мент-антивирус, который время от времени патрулирует территорию.

2. «ДПС — Документы покажи сцуко!» Это концепция UNIX, в ней предполагается доступ на территорию только для проверенных лиц, имеющих такие документы, которые подделать невозможно.

3. «ХЕК — Хоть ебись конем!» Это концепция UNIX-Jail и, например, нынешних устройств Apple. В ней чужая программа может творить всё, что угодно, но она так надежно изолирована от остальных, что никому вреда причинить не может.

Например, в моем дневнике работает концепция ДПС: админский доступ имею только я, админ, которому сервер может безгранично доверять. В ЖЖ, например, концепция безопасности, близкая к ПНХ: специальные системы многократно проверяют контент пользователя и DOM-модели, чтобы вычистить любой вредоносный код, который мог бы внести в свою страницу какой-нибудь из пользователей.

Мне почему-то кажется, что для binoniq.net надо попытаться брать Эпловскую концепцию — ХЕК. То есть разрешать любой JS и не париться. Ей богу, при том объеме возможностей, которые я хочу давать пользователю (включая создание собственного дизайна), я не осилю фильтрование всех пользовательских скриптов, онкликов и уязвимостей css, которые постоянно изобретаются все новые и новые. Да и зачем? Лучше спроектировать систему так, чтобы пользовательский JS не смог причинить вреда другим пользователям. И пусть каждый владелец дневникового аккаунта получит право писать у себя любой JS в коде страницы. А что страшного?

Собственно, что может сделать злоумышленник, способный разместить JS?

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

2. Украсть чужие куки авторизации.

3. Заставить другого посетителя от своего имени невольно выполнить какие-то действия в своем блоге, например сделать новый пост или удалить свою последнюю заметку.

С кражей чужих кук — вопрос решается привязкой куки к IP. Если ты украл чужую авторизацию, то она у тебя с твоего IP не заработает. А если у самого пользователя сменился IP? Это решается введением второго домена, недоступного для атак. В принципе, если речь идет о куках, нам бы даже хватило домена www.--//-- — с точки зрения браузера (поправьте, если я ошибаюсь, но мне помнится, что во всех браузерах так) — это совсем другой сайт со своими куками. Но вроде бы другие хранилища данных (браузерные хранилища, например) так не считают, и http://www.site для них такой же, как http://site, разве нет? Впрочем, не беда, не зря же мы регистрировали вместе с binoniq.net еще и binoniq.ru — вот он и пригодится как вторая поляна.

Система простая: у посетителя есть две авторизованные куки — одна для binoniq.net (где зоопарк аккаунтов и чужих скриптов), и она привязана к IP. Другая для binoniq.ru (закрытый неприступный сайт с одной лишь страницей) — к IP не привязана. Если сменился IP, посетитель временно перекидывается на binoniq.ru, там проверяется его кука для binoniq.net, и если авторизация есть, то возвращается на binoniq.net с командой восстановить куку binoniq.net для нынешнего IP. И с этой кукой посетитель живет, пока снова IP не сменится. Злоумышленник со своими скриптами сможет украсть у посетителя только куку с того же binoniq.net, привязанную к IP, а куку вспомогательного сайта украсть не сможет — вспомогательный сайт недоступен для запуска скриптов.

Остается лишь последняя проблема: как сделать так, чтобы твой браузер от твоего имени не выполнял команды админа, продиктованные злоумышленником, чей дневник ты зашел почитать. Например, я зашел почитать дневник pupkin.binoniq.net, а там JS-команда majax('editor.php',{action:'delete',zametka:345}) — и мой браузер послал на сервер аякс-сигнал от моего имени удалить в моем дневнике заметку 345.

Я думаю, эта проблема тоже решается — созданием уникальных хэшей, при которых команды админа действовали бы только при открытии своего домена leo.binoniq.net или страниц, принадлежащих админу.

Но вот эту часть я пока не очень продумал, потому что в пределах РОДНОГО домена существует возможность подгрузить в невидимом iframe любую другую страницу. То есть, если я правильно понимаю, злоумышленник может сперва средствами JS подгрузить в iframe leo.binoniq.net/245.html, получить доступ к содержимому этого iframe целиком, прочитать там любой секретный хэш и использовать его, сформируя команду: majax('editor.php',{action:'delete',zametka:345,secret_hash:0B34C4A3F8E})

Вопросы к вам:

1. Какие еще неприятности, кроме трех вышеописанных, могут появиться после разрешения использования JS любым пользователям?

2. Каким еще остроумным способом можно запретить браузеру на чужих страницах выполнять команды от имени админа?

PS: В связи с невероятным количеством кретинов в комментах, которые сразу начнут засирать поляну и петросянить, все комментарии скрываются, и я буду раскрывать только ваши — которые умные и по делу.