Укрепление: межсайтовый скриптинг: отражение

Question

Я разрабатываю решение для веб-сервиса, и у меня есть следующий код для создания моих вызовов веб-сервиса:

// Body portion
string postData = JsonConvert.SerializeObject(Body));
byte[] byteArray = Encoding.UTF8.GetBytes(postData);

// Send the query
webRequest.ContentLength = byteArray.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();

, поэтому Body будет объектом JSON, и я намерен его сериализовать, чтобы он могбыть представлен в виде строки для отправки на веб-сервер.Но при сканировании с помощью Fortify жалуется с причиной Cross-Site Scripting: Reflected, на строку

dataStream.Write(byteArray, 0, byteArray.Length);

По рекомендациям не очень понятно, что за исправление

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

Решение XSS состоит в том, чтобы гарантировать, что проверка происходит в правильных местах, и проверяются правильные свойства.

Поскольку уязвимости XSS возникают, когда приложение включает в себя вредоносные данныевывод, один логический подход заключается в проверке данных непосредственно перед тем, как они покидают приложение.Однако поскольку веб-приложения часто содержат сложный и сложный код для создания динамического содержимого, этот метод подвержен ошибкам пропуска (отсутствует проверка).Эффективный способ уменьшить этот риск - также выполнить проверку входных данных для XSS.

Веб-приложения должны проверять свои входные данные для предотвращения других уязвимостей, таких как внедрение SQL-кода, поэтому расширение существующего механизма проверки входных данных приложения включает проверки дляXSS, как правило, относительно легко.Несмотря на свою ценность, проверка входных данных для XSS не заменяет строгую проверку выходных данных.Приложение может принимать входные данные через общее хранилище данных или другой надежный источник, и это хранилище данных может принимать входные данные от источника, который не выполняет адекватную проверку ввода.Следовательно, приложение не может неявно полагаться на безопасность этих или любых других данных.Это означает, что лучший способ предотвратить уязвимости XSS - это проверить все, что входит в приложение и оставляет приложение, предназначенное для пользователя.

Самый безопасный подход к проверке для XSS - это создать белый список безопасных символов, которыеразрешено появляться в содержимом HTTP и принимать ввод, состоящий исключительно из символов в утвержденном наборе.Например, действительное имя пользователя может содержать только буквенно-цифровые символы, а номер телефона может содержать только цифры 0-9.Однако это решение часто невозможно в веб-приложениях, поскольку многие символы, которые имеют особое значение для браузера, должны все же считаться допустимыми входными данными после их кодирования, например доска объявлений веб-дизайна, которая должна принимать фрагменты HTML от своих пользователей.

Более гибкий, но менее безопасный подход известен как черный список, который выборочно отклоняет или экранирует потенциально опасные символы перед использованием ввода.Чтобы сформировать такой список, вам сначала необходимо понять набор символов, которые имеют особое значение для веб-браузеров.Хотя стандарт HTML определяет, какие символы имеют особое значение, многие веб-браузеры пытаются исправить распространенные ошибки в HTML и могут рассматривать другие символы как особые в определенных контекстах, поэтому мы не поощряем использование черных списков в качестве средства предотвращения XSS.Координационный центр CERT (R) в Институте разработки программного обеспечения Университета Карнеги-Меллона предоставляет следующую информацию о специальных символах в различных контекстах [1]:

В содержании элемента уровня блока (в серединепараграф текста):

• "<" особенный, потому что он вводит тег. </p>

• "&" особенный, потому что он вводитсимвольная сущность.

• ">" является особенной, потому что некоторые браузеры рассматривают ее как особую, исходя из предположения, что автор страницы намеревался включить открывающее "<", но пропустил ее вошибка. </p>

Следующие принципы применяются к значениям атрибута:

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

• В значениях атрибутов, заключенных в одинарные кавычки, одинарные кавычки являются специальными, поскольку они отмечают конец значения атрибута.

• В значениях атрибутов без кавычек символы пробела, такие как пробел и табуляция, являются специальными.

• "&" является специальным при использовании с определенными атрибутами, потому что он вводит символьную сущность.

Например, в URL-адресах поисковая система может предоставить ссылку на странице результатов, по которой пользователь может щелкнуть, чтобы повторно запустить поиск. Это может быть реализовано путем кодирования поискового запроса внутри URL, который вводит дополнительные специальные символы:

• Пробел, табуляция и новая строка являются специальными, потому что они отмечают конец URL.

• "&" является особенным, потому что он либо вводит символьную сущность, либо разделяет параметры CGI.

• Не-ASCII-символы (то есть все, что выше 128 в кодировке ISO-8859-1) недопустимы в URL-адресах, поэтому они считаются специальными в этом контексте.

• Символ "%" должен фильтроваться из входных данных в любом месте, где параметры, закодированные с помощью escape-последовательностей HTTP, декодируются серверным кодом. Например, «%» должен быть отфильтрован, если ввод, такой как «% 68% 65% 6C% 6C% 6F», становится «привет», когда он появляется на рассматриваемой веб-странице.

В теле:

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

Серверные сценарии:

• Серверные сценарии, которые преобразуют любые символы восклицания (!) На входе в символы двойных кавычек (") на выходе, могут потребовать дополнительной фильтрации.

Другие возможности:

• Если злоумышленник отправляет запрос в UTF-7, специальный символ «<» отображается как «+ ADw-» и может обходить фильтрацию. Если выходные данные включены в страницу, в которой явно не указан формат кодировки, то некоторые браузеры пытаются интеллектуально идентифицировать кодировку на основе содержимого (в данном случае UTF-7). </li>

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

Если ввод, содержащий специальные символы, должен быть принят и отображен точно, проверка должна кодировать любые специальные символы, чтобы удалить их значение. Полный список кодированных значений ISO 8859-1 для специальных символов приведен как часть официальной спецификации HTML [2].

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

Я попытался поставить HttpUtility.HtmlEncode, но это испортит строку и, следовательно, не работает.

Кто-нибудь знает, как исправить?