Как работать с XSS на NVelocity - PullRequest
       21

Как работать с XSS на NVelocity

2 голосов
/ 12 сентября 2009

Castle Project полон функций, включает в себя несколько потрясающих подпроектов, и разработка с ним была удовольствием.

Моя команда почти готова предоставить заказное EAM , и мы дорабатываем нашу систему. Мы попробовали некоторые базовые XSS-атаки и догадались: все они сработали.

Даже если он будет работать в среде интрасети, мы не хотели бы, чтобы пользователи случайно сломали всю систему, и мы изучаем решения для решения проблем XSS.

NVelocity по умолчанию ничего не экранирует, поэтому этот код:

${entity.Field}

с полем, содержащим такие вещи, как:

<script>alert('xss!')</script>

даст нам хорошее предупреждение xss.

Библиотека Microsoft AntiXSS выглядит неплохо: обрабатывает несколько типов возможных векторов XSS и т. Д. Мы столкнулись с помощником AndyPike , но это решение заставило бы нас провести рефакторинг нескольких тысяч строк. Да, не хорошо И это не будет обрабатывать автоматическое связывание ActiveRecord / NVelocity при редактировании существующих объектов.

Вопрос заключается в следующем: возможно ли / рекомендуется ли использовать методы кодирования выходных данных для исправления движка NVelocity в Castle Project? Так же, как они сделали с Брайлем? У кого-нибудь есть идея получше?

Спасибо!

PS .: Stackoverflowers с использованием Castle Project будет использовать такой патч?

Ответы [ 2 ]

2 голосов
/ 22 февраля 2011

NVelocity может автоматически выходить из вывода без необходимости изменения шаблонов, и вам не нужно изменять код NVelocity.

См. Автоматическая HTML-кодировка вывода NVelocity (EventCartridge & ReferenceInsert)

1 голос
/ 12 сентября 2009

NVelocity по умолчанию ничего не скрывает

О, дорогой. Тогда вам придется много исправлять код.

Неспособность избежать текста, помещаемого в HTML, не является ошибкой, которую вы можете исправить после факта. Да, есть библиотеки, которые отфильтровывают очевидные неверные данные, но они только скрывают проблему, и не очень хорошо. Учитывая широкий диапазон нечетных конструкций, которые будут принимать браузеры, всегда будут способы пропустить через них плохой HTML, и в то же время они будут давать вам ложные срабатывания - например, этот пост будет заблокирован для обсуждения тега <script> .

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

...