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

Question

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

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

Однако у меня остались некоторые вопросы без ответа.

Первый

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

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

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

Второй

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

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

Так что я буду делать? Использовать регулярные выражения для фильтрации всех тегов?

Третий

Существует также еще один тег, который вы можете использовать, называемый «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

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

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

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

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

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

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

Answer 4

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

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

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