ASP.Проблема безопасности NET ScriptManager - PullRequest
0 голосов
/ 03 октября 2018

Я поместил следующий код для включения запроса на основе AJAX на странице aspx:

<asp:ScriptManager ID="ScriptManager1" runat="server"></asp:ScriptManager>

Однако при сканировании кода с использованием Fortify он жалуется, что это создает угрозу безопасности

Объяснение:

Microsoft AJAX.NET (Atlas) использует JSON для передачи данных между сервером и клиентом.Фреймворк создает ответы, состоящие из действительного JavaScript, который можно оценить с помощью тега, и поэтому уязвим для кражи JavaScript [1].По умолчанию платформа использует метод POST для отправки запросов, что затрудняет генерацию запроса из вредоносного тега (поскольку теги генерируют только запросы GET).Тем не менее, Microsoft AJAX.NET предоставляет механизмы для использования запросов GET.Фактически, многие эксперты рекомендуют программистам использовать запросы GET, чтобы использовать кэширование браузера и повысить производительность.

Приложение может быть уязвимо для перехвата JavaScript, если оно: 1) использует объекты JavaScript в качестве формата передачи данных 2)Обрабатывает конфиденциальные данные.Поскольку уязвимости, связанные с перехватом JavaScript, не являются прямым следствием ошибки кодирования, пакеты правил для безопасного кодирования обращают внимание на потенциальные уязвимости перехвата JavaScript, идентифицируя код, который, по-видимому, генерирует JavaScript в ответе HTTP.

Веб-браузеры обеспечиваютединая политика происхождения для защиты пользователей от вредоносных сайтов.Одна и та же политика происхождения требует, чтобы для доступа JavaScript к содержимому веб-страницы как JavaScript, так и веб-страница должны происходить из одного домена.Без единой политики происхождения вредоносный веб-сайт может обслуживать JavaScript, который загружает конфиденциальную информацию с других веб-сайтов, используя учетные данные клиента, отбирает ее и передает злоумышленнику.Перехват JavaScript позволяет злоумышленнику обойти ту же Политику происхождения в случае, если веб-приложение использует JavaScript для передачи конфиденциальной информации.Лазейка в той же политике происхождения заключается в том, что она позволяет включать и выполнять JavaScript с любого веб-сайта в контексте любого другого веб-сайта.Несмотря на то, что вредоносный сайт не может напрямую проверить какие-либо данные, загруженные с уязвимого сайта на клиенте, он все равно может воспользоваться этой лазейкой, настроив среду, которая позволяет ему наблюдать выполнение JavaScript и любые соответствующие побочные эффекты, которые он может иметь,Поскольку многие приложения Web 2.0 используют JavaScript в качестве механизма передачи данных, они часто уязвимы, а традиционные веб-приложения - нет.

Самый популярный формат для передачи информации в JavaScript - это JavaScript Object Notation (JSON).JSON RFC определяет синтаксис JSON как подмножество литерального синтаксиса объекта JavaScript.JSON основан на двух типах структур данных: массивы и объекты.Любой формат передачи данных, в котором сообщения можно интерпретировать как один или несколько допустимых операторов JavaScript, уязвим для перехвата JavaScript.JSON упрощает захват JavaScript благодаря тому, что массив JSON сам по себе является допустимым оператором JavaScript.Поскольку массивы являются естественной формой для передачи списков, они обычно используются везде, где приложению необходимо передавать несколько значений.Иными словами, массив JSON напрямую уязвим для перехвата JavaScript.Объект JSON уязвим только в том случае, если он заключен в какую-то другую конструкцию JavaScript, которая сама по себе является допустимым оператором JavaScript.

И рекомендации приведены ниже:

Рекомендации:

Все программы, которые общаются с использованием JavaScript, должны принимать следующие защитные меры: 1) Отклонять вредоносные запросы: включать трудно угадываемый идентификатор, такой как идентификатор сеанса, как часть каждого запроса, который будет возвращать JavaScript.Это устраняет атаки подделки межсайтовых запросов, позволяя серверу проверять источник запроса.2) Запретить непосредственное выполнение ответа JavaScript: включите в ответ символы, которые не позволяют успешно передать его интерпретатору JavaScript без изменений.Это не позволяет злоумышленнику использовать тег для наблюдения за выполнением JavaScript.Лучший способ защититься от взлома JavaScript - это использовать обе защитные тактики.

Я до сих пор не совсем уверен, как этот ScriptManager может представлять угрозу безопасности и как его устранить?

1 Ответ

0 голосов
/ 03 октября 2018

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

Перехват JavaScript (также известный как перехват JSON)является устаревшей проблемой безопасности, и вы не должны относиться к ней серьезно, когда Fortify жалуется на это.Короче говоря, угон JavaScript был проблемой давным-давно, когда веб-браузеры были очень незрелыми и не содержали защиты, которые они содержат сегодня.Эти браузеры теперь защищают от этого, поэтому вам больше ничего не нужно делать. Это больше не проблема безопасности (см. Ссылку).

Самое главное, что руководство Fortify («трудно угадываемый идентификатор») для предотвращения проблемы - это нонсенс.Это руководство взято из старой исследовательской работы, написанной сотрудниками Fortify, и в то время оно имело смысл из-за отсутствия других способов предотвращения атаки.Как правило, вы никогда не должны отправлять json в JavaScript eval() - и этого будет достаточно, чтобы остановить взлом JavaScript, даже если браузеры не помешали этому.

В документации Fortify они содержат ссылку на оригинальный документ об угоне JavaScript.Когда я впервые увидел ту же проблему, я был настолько обеспокоен этой проблемой, что потратил неделю, пытаясь понять и реализовать ее (тот же пример, что и в статье) - пробуя ее в Chrome, Firefox и IE, и находячто ни одна из этих попыток атаки не сработала.Только тогда я углубился и обнаружил ссылку выше и другие о том, почему JavaScript-хакерство больше не является проблемой безопасности.

Чем больше вы используете Fortify, тем больше вы найдете много бессмысленных ложных срабатыванийи, к сожалению, это один из самых болезненных для понимания.MicroFocus не заинтересован в обновлении своих правил: когда люди пробуют Fortify и обнаруживают, что получается много результатов, которые не появляются в других инструментах, люди покупают Fortify, предполагая, что он лучше благодаря таким результатам.Правда противоположна: это не лучше, это просто вызывает больше бесполезных ложных срабатываний, которые раздражают людей, которые используют инструмент.Но люди, которые используют инструмент, обычно не люди, принимающие решение о покупке, поэтому у MicroFocus нет стимулов для обновления правил - ложные срабатывания работают в их пользу для увеличения продаж!

...