Вопросы о внедрении Javascript

Question

Я читал на asp.net MVC сайт обучения о JavaScript инъекций, и человек это откровение.

Я никогда даже не осознавал и не думал о том, чтобы кто-то использовал JavaScript для выполнения каких-то странных инъекционных атак.

Это однако оставило меня с некоторыми оставшимися без ответа вопросами.

Первый

Когда вы используете html.encode? Например, вы используете его только тогда, когда собираетесь отображать информацию, предоставленную этим пользователем или другим пользователем?

Или я использую это для всего. Например, если у меня есть форма, которую отправляет пользователь, эта информация никогда не будет отображаться никому из пользователей, должен ли я по-прежнему использовать html.encode?

Как бы я сделал это, как я не уверен, как поместить внутрь скажем и Html.TextBox() тег html.encode.

второй

Что происходит, скажем, у меня на сайте есть богатый редактор HTML. Пользователь имеет право использовать его и делать вещи смелыми и что угодно. Теперь я хочу отображать информацию обратно пользователю через ярлык. Я не могу Html. Закодировать его с тех пор все жирным шрифтом и прочее не будет отображаться.

Тем не менее, я не могу оставить все так, как есть, поскольку что помешает пользователю добавить некоторые атаки Javascript?

Так что я буду делать? Используйте Regex, чтобы отфильтровать все теги?

В третьих

Существует также еще один тег, который вы можете использовать, называемый "AntiforgeryToken", когда бы вы использовали этот тег?

Спасибо

редактировать

Почти все говорят, что используют "Белый список" и "Черный список", как мне написать этот список и сравнить его с входящими значениями (примеры в C# были бы хорошими)?

Answer 1

Хороший вопрос!

1. Для первого ответа, я хотел бы рассмотреть здесь на предыдущий заданный вопрос. Как говорится в ответе, использование HTML Encode не защитит вас полностью от всех атак XSS. Чтобы помочь с этим, вам следует рассмотреть возможность использования библиотеки веб-защиты Microsoft (в частности, AntiXSS), доступной от Microsoft.

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

3. Токен AntiforgeryToken предотвращает подделку запросов (CSRF), поскольку он дает пользователю файл cookie, который проверяется по отношению к отображаемому полю формы при публикации страницы. Нет никакой причины, по которой я знаю, что это означает, что вы не можете использовать это во всех ваших формах.

Answer 2

Используйте HTML Encode для любых отображаемых данных, которые были отправлены пользователем. Вам не нужно использовать его при отправке в базу данных, иначе вы получите странные данные, такие как: Simon '&' Sons. На самом деле я не вижу вреда использовать его на любом контенте, динамически записываемом на страницу.

Используйте список разрешенных тегов и откажитесь от всего остального для вашего HTML-редактора. Как говорили люди, используйте белый список.

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

Смотрите здесь для получения дополнительной информации: http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx

Как его использовать: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/

Answer 3

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

Не полагайтесь на проверку на стороне клиента для проверки ввода пользователя. Проверка на стороне клиента отлично помогает пользователю вводить правильные данные. Но злонамеренный пользователь не будет использовать это и может обойти проверку на стороне клиента. Проверка на стороне клиента никогда не должна рассматриваться как исправление безопасности. Использование JavaScript для проверки ввода не должно использоваться. Как видите, javascript очень легко изменить и изменить на любой html-странице. Также javascript может быть отключен в браузере. Так что дайте дополнительную проверку в вашем коде за файлом.

Дополнительно проверяйте ввод каждый раз, а не только когда данные первоначально принимаются. Например, если вы установили cookie-файл, убедитесь, что cookie-файл имеет одно и то же значение и является правильным для каждого запроса. Злонамеренный пользователь может изменить и изменить значение в любое время в течение сеанса.

Answer 4

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

Я бы пошел со следующими основными правилами:

1. Очистить все входные данные, удалив известные вредоносные разделы (например, <script> теги в богатом редакторе HTML). Сопоставление с образцом на основе регулярных выражений обычно используется для такой очистки.

2. Удалите все входные данные, которых нет в вашем белом списке допустимых значений.

3. Кодируйте любой HTML-код перед сохранением в базе данных и декодируйте его обратно, когда он извлекается для отображения.

Редактировать:@Phoenix говорит о проверке в этом контексте, поэтому я решил добавить это. Я уже говорил об этом и повторяю: я не против проверки на основе сценариев. Я только предостерегаю людей не полагаться на это прямо. Распространенным шаблоном проектирования является проверка основных критериев с использованием проверки на основе сценариев и применение строгой проверки на стороне сервера при отправке этих данных.