Ruby on Rails и предотвращение XSS
В конечном счете решение сводится, более ли полезно иметь дело с ошибками прикладного уровня как эта обработка исключений использования, или с помощью Вашего собственного прокрученного домом механизма как возврат кодов статусов. Я не думаю, что существует твердое правило, о котором лучше, но я рассмотрел бы:
- , Кто называет Ваш код? Действительно ли это - общедоступный какой-то API или внутренняя библиотека?
- , Какой язык Вы используете? Если это - Java, например, то бросок (проверенного) исключения помещает явную нагрузку на Вашу вызывающую сторону для обработки этого состояния ошибки в некотором роде, в противоположность статусу возврата, который мог быть проигнорирован. Это могло быть хорошо или плохо.
- , Как другие состояния ошибки в том же приложении обработаны? Вызывающие стороны не захотят иметь дело с модулем, который обрабатывает ошибки особенным способом в отличие от чего-либо еще в системе.
- , Сколько вещей может пойти не так, как надо с рассматриваемой стандартной программой, и как они были бы обработаны по-другому? Рассмотрите различие между серией блоков выгоды, которые обрабатывают различные ошибки и переключатель на коде ошибки.
- у Вас есть структурированная информация об ошибке, которую необходимо возвратить? Выдача исключения дает Вам лучшее место для помещения этой информации, чем просто возврат состояния.
4 ответа
Руководство по безопасности Ruby on Rails довольно подробно описывает специфические для Rails проблемы, которые вы должны учитывать при разработке безопасности для своего веб-сайта.
Метод h по-прежнему позволяет избежать всего HTML внутри строки. Вы должны использовать этот метод везде, где вы выводите контент.
<%=h @recipe.description %>
Это поведение будет изменено в Rails 3. Там весь вывод будет экранирован по умолчанию, и вам нужно будет явно указать, чтобы не экранировать его. Между тем, если вы часто забываете использовать этот метод h , вы можете попробовать плагин Safe ERB .
Метод sanitize - это хороший способ выборочно удалить определенные теги из содержимого. Например, если вы хотите разрешить пользователю выделять полужирным шрифтом и курсивом их вывод вместе с добавлением ссылок, вы можете сделать это.
<%= sanitize @recipe.description, :tags => %w[b i a], :attributes => %w[href] %>
Как упомянул Оливер, дополнительную информацию можно найти в Руководстве по безопасности .
Что касается лучших практик, я бы порекомендовал следующее:
Всегда используйте помощники формы rails (form_for и т. Д.), Если вы пишете свою собственную форму, вы открываете себя для атак CSRF.
Хотя использование функции h () будет экранировать текст, когда он записывается на страницу, вы все равно получите эксплойты XSS, сохраненные в вашей базе данных. Использование XSS_terminate подключаемого модуля разделяет ввод по мере его сохранения.
Не забывайте, что ваше приложение работает в стеке других приложений (Rails, Apache, MySQL, ваша ОС по своему выбору), каждое из которых имеет свои собственные проблемы безопасности.
Метод очистки Rails довольно хорош, но он не гарантирует правильной формы и, скорее всего, подвергнется атаке из-за базы установки. Лучше использовать либо html5lib (действительно лучший, если не самый быстрый или самый рубиновый), либо Sanitize или Loofah