Безопасность в приложении Rails — данные, отправленные пользователем

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

Во внешнем интерфейсе я использую TinyMCE для приема пользовательского ввода. Насколько я понимаю, TinyMCE удалит любые подозрительные теги (например, <script>) из пользовательского ввода перед отправкой на сервер. Кажется, это можно обойти, отключив javascript на странице, что позволит пользователю свободно управлять текстовой областью. TinyMCE рекомендует использовать javascript для создания TextArea. Поэтому, если пользователь отключит javascript, текстовой области не будет. Это стандартное решение? Это похоже на взлом.

С другой стороны, как лучше всего удалить вредоносный код? Хотел бы я поставить какую-то проверку в методах создания и обновления внутри моего контроллера комментариев? Есть ли какие-то встроенные в Rails функции, которые могут помочь в этом?

При отображении информации обратно пользователю я предполагаю, что не хочу избегать разметки HTML (с <%= h *text*%>), потому что именно так она хранится в бэкэнде. Это плохая практика?


ruby-on-rails security xss
person Community    schedule 22.11.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Обычно я большой поклонник очистки данных перед их добавлением в базу данных. Это спорная практика, но я обычно склоняюсь к этому.

Я использую модифицированную версию старого плагина white_list, чтобы не удалять html, а конвертировать все, что мне нужно, в более безопасный формат.

<tag>

становится

&lt;tag&gt;

Таким образом, я на самом деле не меняю содержание представления.

Есть несколько плагинов, которые специально обрабатывают очистку с использованием модели белого/черного списка.

http://github.com/rgrove/sanitize/ # Не использовал, но выглядит очень интересно

http://github.com/rgrove/sanitize/ # Б/у, неплохо

Существует также act_as_sanitized, но у меня нет реальной информации об этом.

И, конечно же, с помощью функции h().

person nowk    schedule 22.11.2009

arrow_upward
0
arrow_downward

Ваши подозрения оправданы, но создание текстовой области в javascript не сделает вас менее уязвимым. Пользователь всегда может использовать что-то вроде curl, чтобы принудительно отправить форму, даже не посещая ваш сайт через веб-браузер.

Следует исходить из того, что пользователь может публиковать вредоносные скрипты в комментариях и избегать их во внешнем интерфейсе. Использование <%= h(...) %> является одним из способов сделать это, или вы можете использовать метод sanitize таким же образом. Он удалит все скрипты и экранирует весь остальной html, за исключением нескольких общих тегов, которые не наносят вреда. Документация по санации.

person erik    schedule 22.11.2009
comment
Итак, как мне сохранить разметку, созданную TinyMCE, если я экранирую теги во внешнем интерфейсе. Например, если я создаю комментарий жирным шрифтом, то в бэкенде сохраняется следующая строка: ‹strong›text‹/strong›. Я хочу, чтобы пользователь видел жирный текст, когда он отображается во внешнем интерфейсе, а не буквальную строку с тегами разметки html. - person ; 22.11.2009
comment
Вот тут-то и появляется ‹%= sanitize(my_string) %›. Он будет избегать только плохих тегов, таких как ‹script›, но позволит правильно отображать безопасные теги, такие как ‹strong› и ‹em›. - person erik; 23.11.2009

arrow_upward
0
arrow_downward

В дополнение к предложениям Nowk есть также плагин xss_terminate. Я использовал его в некоторых своих приложениях. Я обнаружил, что он прост в использовании, он почти не требует настройки и работает как часы.

person mtyaka    schedule 22.11.2009