#query-string
#запрос-строка
Вопрос:
У меня есть страница, которая не использует строки запроса. например. https://testsite.com/defalut.aspx
Наш сетевой администратор запускает проверку на уязвимость и сообщает, что есть проблема с некоторыми страницами. Это URL-адрес, который нарушает его, например. https://testsite.com/default.aspx?<<<<<<<<<< foo»бар’314>>>>>=1
Я знаю, что программное обеспечение, которое он использует, добавляет эту строку запроса во время теста, но как я могу исключить подобные строки запроса на страницах, где нет проверки строки запроса?
Я подумал, что, поскольку для строки запроса нет проверки, страница загрузится без проблем.
Я использую Visual Studio 2019 C #, IIS 10.
Отчет о результатах
Using the GET HTTP method, Nessus found that :
The following resources may be vulnerable to SQL injection (on
parameters names) :
> /default.aspx?'+convert(int,convert(varchar,0x7b5
d))+'=1
-------- request --------
GET /default.aspx?'+convert(int,convert(varchar,0x7b5d))+'=1
HTTP/1.1
Host: testsite.com
Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1
Accept-Language: en
Connection: Close
Cookie: ASP.NET_SessionId=f1lv3mbn4qodbzm44wjhlhizxswe3
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0)
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png,
*/*
------------------------
-------- output --------
<html>
<head>
<title>ORA-12520: TNS:listener could not find available handler for requ
ested type of server</title>
<meta name="viewport" content="width=device-width" />
<style>
------------------------
Спасибо
Комментарии:
1. Прокомментировал, но изменил комментарий на ответ, хотя вы, вероятно, получите лучшие ответы от других 🙂
Ответ №1:
Я думаю, вам нужно больше информации.
Тест на проникновение выявит проблему, если ответ на запрос, подобный показанному, содержит некоторые детали, которые указывают на возможную уязвимость, например, некоторые строки запроса, появляющиеся в ответе, могут указывать на XSS и т. Д.
Результаты сканирования предоставят дополнительную информацию о том, почему этот запрос выявляет потенциальную уязвимость — попросите своего сетевого администратора предоставить доступ к полному отчету, поскольку это позволит вам определить, существует ли потенциальная проблема, которую вам нужно устранить, или это ложное срабатывание. Я предполагаю, что используемая вами структура отражает строку запроса в ссылках на странице, но это реальное предположение.
Немного расширено в свете обновления нашего чата и вопросов. Для уязвимостей, таких как инъекционные атаки и XSS, основными средствами защиты являются внесение входных данных в черный список, ввод в белый список и нейтрализация ненадежных данных.
Черный список, как правило, является последним средством — какие бы шаблоны вы ни блокировали, вероятно, найдутся способы обойти это.
Белый список, если это возможно, может быть эффективным для предотвращения поступления вредоносных данных через ваше приложение, но сам по себе может быть недостаточным. Если какой-либо контент на вашем сайте поступает из сохраненных данных, существует ли какой-либо другой способ проникновения вредоносных данных? Существуют ли какие-либо другие приложения, которые могут обновлять данные? У кого есть доступ к непосредственному выполнению sql? Социальная инженерия — это реальная угроза, когда людей, имеющих доступ, можно обманом заставить делать опасные вещи.
Нейтрализация ненадежных данных означает разные вещи в зависимости от угрозы. При внедрении sql ненадежный ввод нейтрализуется с помощью подготовленных операторов — никогда не объединяйте пользовательский ввод в оператор.
Для XSS нейтрализация обычно означает удаление любых данных, которые могут быть использованы злонамеренно. Обычно это происходит при выводе данных на странице, а не во время ввода, поскольку соответствующая форма экранирования зависит от того, где в содержимом страницы включены данные — в блоке текста, или в атрибуте href, или в скрипте на странице.
В вашем случае, поскольку вы никогда не ожидаете параметров запроса, вы, вероятно, можете использовать довольно простой подход. Либо внести в белый список (отклоняя любой запрос с запросом), либо нейтрализовать ввод (удаляя любой запрос). Если у вас есть веб-сервер, такой как Apache httpd, перед вашим сервером приложений, я думаю, что это можно сделать с помощью MOD_REWRITE, иначе я думаю asp.net имеет аналогичные возможности перезаписи запросов.
Включение в белый список или нейтрализация просто влияет на пользовательский интерфейс и, вероятно, не имеет значения — реально маловероятно, что реальный пользователь будет сидеть за экраном, отправляя потенциально вредоносные запросы. Большинство общедоступных сайтов завалены попытками автоматической атаки, аналогичными вашему тесту на проникновение.
Похоже, что часть содержимого вашей страницы зависит от данных из базы данных, поэтому, хотя приведенное выше позволит устранить ваши предупреждения о тестировании пера, стоит подумать о том, чтобы избежать вывода, чтобы быть действительно безопасным. Я предполагаю , что asp.net имеет некоторые встроенные функции для поддержки этого.
Я также немного обеспокоен тем, что сообщения об ошибках попадают в заголовок страницы, как это обычно бывает — подробная информация об ошибках сама по себе является уязвимостью, поскольку она может дать злоумышленникам много полезной информации о реализации вашего сайта и полезную обратную связь о последствиях различных попыток атаки.
Лучшее место для дополнительной информации — веб-сайт OWASP
Комментарии:
1. Спасибо, Крис, я не могу опубликовать что-либо из отчета. Я работаю по очень строгим правилам. Что мне нужно искать, чтобы увидеть, является ли это ложным срабатыванием? Я думаю, что «<» или «>» заставляет его возвращать XSS, правильно?
2. Привет, полностью понимаю, что результаты теста пера не могут быть предоставлены здесь, но если у вас есть отчет, дает ли отчет вам HTML-ответ на этот запрос? И говорит ли он точно, какую проблему он определил (или думает, что она определила)
3. Ложное срабатывание зависит от ваших знаний о приложении — т.Е. Если вы видите все, что отмечено в отчете, но вы можете с абсолютной уверенностью сказать, что это не может быть проблемой, тогда это ложное срабатывание. Однако параметры запроса, отраженные в исходном коде html, могут быть действительно проблематичными (например, ссылка со строкой запроса, содержащей исполняемый JavaScript, который отправляется по электронной почте). Обычно подобные риски управляются как экранированием вывода, так и проверкой ввода — в вашем случае, если вы не ожидаете параметров запроса, можете ли вы настроить его так, чтобы он возвращал 400 ответов, если таковые будут получены?
4. Привет, Крис, я смог получить первую часть отчета и изменить любую информацию, которую можно было бы идентифицировать. Если страница страницы не использует строки запроса, как это может вызвать сообщение такого типа? Спасибо
5. Вау, увидел обновление, это реальная проблема — вы получаете ошибку ORA в заголовке страницы. Это требует небольшого исследования, хотя вы не ожидаете параметров запроса, я предполагаю, что asp.net выполняет некоторую обработку, прежде чем она попадет в ваш код, уязвимый для этой конкретной атаки. Заголовок может выдавать злоумышленнику очень полезную информацию