Как обезопасить систему с полным клиентским доступом к HTML?

Question

[Litiy]

Есть задача — дать полный доступ клиенту к своему html-контенту. Как tumblr.
Вопрос в том, какие есть угрозы в этом случае и какие средства защиты.

Основная угроза имхо – воровство куки, доступ к админке других юзеров.

Защита:
-httponly cookies
-отдельные поддомены для каждого «автора» и изоляция кук в поддоменах

Есть ли еще какие-то угрозы и методы защиты?
Есть ли способ единой аутентификации при такой схеме или придется аутентифицироваться на каждом отдельном поддомене?

Answer 1

[egorinsk]

Если вы даете полный доступ, что мешает злоумышленнику показать страницу «пожалуйста, в целях безопасности введите свой пароль заново»? Или установить на странице комплект вредоносных программ, внедряющихся в систему при открытии страницы за счет уязвимости в браузере?

Даже технически грамотного пользователя можно поймать на этом.

Comments

[egorinsk]

А вообще, стоило бы сделать отдельные домены 2 уровня для блогов, и отдельный для админки — чтобы никакими играми с document.domain куки нельзя было вытянуть.

[Litiy]

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

Answer 2

[frostosx]

1) вырезать регулярными выражением все скрипты — очевидно
2) вырезать стили — чтобы свои контролы не ставили поверх наших
3) вырезать/дополнять_префиксами классы и id из html-элементов — чтобы клиентские элементы не могли использовать «наши» стили и обработчики

Comments

[frostosx]

Не забываем про свойства элементов для событий onClick etc

[egorinsk]

Не пытайтесь ни в коем случае вырезать срикпты регулярным выражением — это почти 100% фейл, так как есть очень много видов нестандартных и битых тегов, обходящих фильтры ( www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet ). Используйте библиотеки, которые разбирают HTML на дерево и проходят по нему с белым списокм разрешенных тегов.

[frostosx]

egorinsk, спасибо, не знал, что так много способов обойти.
Тогда PHPQuery?

[egorinsk]

Нет, нив коем случае. Есть специальные библиотеки вроде Jevix или htmlLawed, HTML purifier или kses. Какая из них лучше и современнее, и какие подводные камни при их использовании, я не знаю, так как не работал с ними.

[Litiy]

Задача была поставлена иначе – не очищать код, а дать полный неограниченный доступ к HTML. Но при этом ограничить авторов от вмешательства друг к другу, воровства общих кук.

[Litiy]

Сейчас как раз используется система на основе white-listing, но цель — от нее избавиться, дать неограниченный доступ без взаимной кражи кук. Грубо говоря — мультиблоггинговый сервис с полной кастомизацией.

[Николай Турнавиотов]

а поставить нормальную мультиюзер cms вроде вордпресса не подходит?

[Litiy]

Нет. Я просто объяснил примерно цель. Это не блоггинг-сервис, а конструктор квестов

[Николай Турнавиотов]

Хм. я когда-то хотел конструктор квестов десктопный написать

[Litiy]

Десктопные есть, см. URQ, QSP, INSTEAD

Answer 3

[merlin-vrn]

HTTPS и клиентские сертификаты. Аутентификация по сертификату (защита от кражи — можно хоть токены использовать), в результате чего получаем уникальный идентификатор пользователя — commonName из сертификата. При проверке прав (авторизации) привязывайтесь к commonName.

Общая аутентификация будет хоть на нескольких несвязанных доменах, и им даже иметь какую-то общую базу необязательно — общим на них будет только корневой сертификат вашего ЦС, которым подписаны все сертификаты клиентов.

Пароли в принципе тоже не обязательны, можно внедрить — тогда общая база будет нужна, а аутентификация получится двухфакторая.

Comments

[Litiy]

Да, это вариант. Но вы представьте как сделать доступ по сертификату широкой публике посетителей. Например посещаемость хотя бы 10000 уников в сутки, каждому сертификат? Мне интересно именно как это сделано безопасно в сервисах типа tumblr.

Answer 4

[Владислав]

Как вариант, фильтрация пользовательского HTML, например, при помощи HTML Purifier и отдельные поддомены.

Comments

[Litiy]

Задача поставлена иначе, ПОЛНЫЙ доступ к HTML, см. выше.

Answer 5

[frostosx]

Другие языки разметки годятся? Я имею в виду BBCode.

Comments

[Litiy]

Это ничем не лучше white-listingа, разве что обычным пользователям разобраться проще.