Необходимость использования вики-разметки на коллективных сайтах

В Кампусе активно используется вики-разметка для самых различных целей. В статье я попробую пояснить необходимость ее введения и почему просто не дать вставлять любой HTML-код.

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

Ситуация резко меняется на коллективных сайтах (а это все web 2.0 сайты), когда предоставление возможности вставки любого HTML-кода может привести:

  • Выполнению любых действий от лица других пользователей (накрутка голосов, отправка спамерских сообщений, удаление постов, и т.п.)
  • Перехвату паролей путем разлогиневания пользователей и просьбой ввести пароль на подмененном и контролируемом вломщиком сайте

Ну и куче других проблем...

Вы скажете, что кому это нужно?

Атака на ЕТИС[править]

etis3.png

Возьмем абстрактный ЕТИС и положим, что кто-то может вставить в него произвольный javascript-код. Пусть разработчики гордятся, что защитили ЕТИС от атак путем создания временных ссылок на различные действия и HASP-ключами.

Тогда атака на преподавателя может быть такой:

  1. Создать страницу в ЕТИС с javascript-кодом, который проведет атаку на преподавателя.
  2. Заманить преподавателя на зараженную страницу. Надо просто чтобы он перешел на нее по ссылке.
  3. Нарисовать на странице невидимый iframe, ведущий, например, на страницу успеваемости группы.
  4. У преподавателя загрузится в iframe страница успеваемости, на которой есть форма отправки или изменения оценки. Так как страница загрузиться у уже авторизованного преподавателя, то у него есть все права на управления оценками и любые действия над оценками будут выполнены с точки зрения системы безопасности самим преподавателем.
  5. При помощи javascript с зараженной страницы получить доступ к содержимому iframe и выдернуть от туда "безопасные временные ссылки", сформированные для преподавателя и все необходимые данные для выставления/изменения оценки нужному студенту.
  6. При помощи javascript на зараженной странице сгенерировать GET/POST-запрос на изменение или добавление оценки. Сам запрос выполниться браузером преподавателя и от лица преподавателя. Так что даже если изменение оценок будет защищено HASP-ключом, то раз ключ вставлен в компьютер преподавателя, запрос все равно пройдет.

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

Примеры кода[править]

Пример кода на jQuery, нахадящий все скрытые поля input в iframe:

jQuery("iframe").contents().find("input[type=hidden]").val();

Именно в них обычно хранят CSRF-токены.

Пример кода для получения всех ссылок из iframe:

jQuery("iframe").contents().find("a").val("href");

Пример получения содержимого страницы в iframe:

jQuery("iframe").contents().find("body").html();

Весь полученный HTML-код злоумышленник может отправить обычным POST-запросом на свой сайт для последующего анализа.

Еще раз важные моменты:

  • Преподавателю достаточно зайти на зараженную страницу в ЕТИС. Все остальное выполняется скрытно от него и без его участия.
  • Временные ссылки, CSRF-токены и HASP-ключи от такой атаки защитить никак не могут т.к. все действия выполняются авторизованным пользователем.

Защита[править]

Как от этого защититься?

Атака стала возможной из-за того, что на сайте с ЕТИС злоумышленник мог вставить javascript. Значит надо запретить вставлять javascript. Но этого может быть недостаточно, потому что существуют и другие способы атаки и надо исключить целый ряд стандартных HTML-тегов, потенциально несущих опасность. В том числе и iframe.

iframe[править]

Чем плохи iframe с точки зрения безопасности? Вот еще один способ атаки:

Злоумышленник рисует сайт похожий на ЕТИС и вставляет его на какой-либо странице в ЕТИС. Допустим на этой странице он пишет нечто:

"Внимание! мы обнаружили что Ваш компьютер заражен вирусом. У вас осталась 60 секунд для изменения пароля:" ну и нарисует фиктивную форму ввода старого пароля и нового, при вводе которых они будут отправляться на сайт злоумышленника.

Преподаватель, зайдя на такую страницу, видит как ЕТИС его сейчас забанит за вирусы и, боясь бана в ЕТИС, просто послушно дарит вводит свой пароль.

Итак, iframe надо тоже запретить... Но какже тогда вставлять видео с YouTube, презентации со SlideShare и т.п. ведь все они дают embed-код в виде iframe? Ответ прост: надо запретить пользователям вставлять iframe, на разрешить использовать специальную (не html) разметку, из которой бы генерировался <iframe> и другой опасный код.

Алгоритм для безопасной вставки видео с YouTube может быть такой:

  • Вырезать из пользовательского текста все опасные теги
    <iframe></iframe>
  • Найти в пользовательском тексте такое содержимое {{ видео:youtube | capq99Ewckg }} и заменить его на
    <iframe width="420" height="315" src="//www.youtube.com/embed/capq99Ewckg" frameborder="0" allowfullscreen> </iframe>
  • Показать результат пользователю

Вот этот странный код {{ видео:youtube | capq99Ewckg }} и называют вики-разметкой.

Заключение[править]

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

Комментарии

Ну и, кстати, есть ведь плюсы. Продвинутые студенты могут, изучив ЕТИС, создавать удобные инструменты, подключив их к преподавательскому аккаунту. А-ля средство коллективной работы. Ну, или помогать ему заполнять отчеты.

Это будут новые классы атак:

  • bug fix-attack
  • unusability fix-attack

относящиеся к гуманным атакам.

Университету надо будет тогда установить денежную премию за лучшую гуманную атаку года, выплачивающуюся из премии допустившего атаку разработчика.