Я работаю над соблюдением требований PCI. Один из недостатков:
3.1.4. Слепое внедрение SQL (httpgenericscriptblindsqlinjection)
Предлагаемые решения просты: «Убедитесь, что веб-приложение проверяет и кодирует вводимые пользователем данные, прежде чем использовать их в запросе SQL».
Похоже, что это связано с OWA, поскольку на нем размещается: «Обнаружена слепая SQL-инъекция на http: /// owa /? P = + ADwscript + AD4alert (42) + ADw / script + AD4 с использованием метода GET»
Кто-нибудь знает, как исправить именно эту проблему?
Я думаю, что термин «SQL-инъекция» здесь вводит вас в заблуждение. На самом деле они описывают атаку XSS (межсайтовый скриптинг).
Вы можете прочитать об этой конкретной уязвимости здесь: http://msdn.microsoft.com/en-us/library/dd565635%28v=vs.85%29.aspx
В принципе, http:///owa/?P=+ADwscript+ AD4alert(42)+ADw/ script+AD4 где-то возвращает точный ввод, полностью не очищенный, в документе, в котором не указан его тип кодировки.
Это означает, что этот код фактически отображается и анализируется вашим браузером как <script>alert(42)</script> при загрузке отображается всплывающее окно «42».
Этот конкретный сценарий не очень непослушный, но вы можете сделать некоторые действительно вредоносные вещи для учетных записей людей, если перенаправите их на этот URL-адрес на своем сервере. Например, встраивание неприятного JS-файла с вашего сервера, который перехватывает все входные данные на странице или вставляет вирус на страницу и т. Д.
Однако я не могу найти никаких признаков того, что OWA имеет какую-либо из этих уязвимостей, поэтому могу только предположить, что на вашем сервере OWA что-то запущено. еще который имеет эту уязвимость.
Я только что попробовал этот эксплойт на сервере Exchange 2010, который у нас есть, и он ничего не делает. Если это компьютер SBS 2011, как, кажется, указывают ваши теги, то обычно сайты удаленного доступа / owa работают только под /remote/ папка. У вас есть другое приложение IIS по умолчанию, работающее в корне домена?