«Техника сетевых атак»
Вид материала | Краткое содержание |
- Комплексный подход к обнаружению сетевых атак, 70.8kb.
- Предотвращение атак: революция или эволюция?, 98.18kb.
- Темы курсовых работ по дисциплине «Безопасность и управление доступом в ис» Модель, 15.44kb.
- Технические особенности сетевых сообществ и их педагогические следствия, 124.33kb.
- А. А. Грабко научный руководитель В. С. Горбатов, к т. н., доцент Московский инженерно-физический, 29.26kb.
- Это комплекс взаимосвязанных и согласованно функционирующих программных и аппаратных, 277.11kb.
- Лекция: Определение локальных сетей и их топология Вэтой лекции говорится о базовой, 250.42kb.
- Лекция: Определение локальных сетей и их топология Вэтой лекции говорится о базовой, 318.77kb.
- Тутер Нина Валерьевна Клинико-психофизиологический анализ панических атак при различных, 560.1kb.
- Использование современных компьютерно-сетевых технологий в информационном обеспечении, 158.29kb.
Протокол HTTP
- В этой главе:
- Сеанс работы с HTTP-сервером
- Удаленное выполнение программ
- Модификация и удаление ресурсов на сервере
- Механизмы аутентификации
- Интерфейс CGI
- История возникновения HTML
Бесспорно, HTTP (Hyper Text Transfer Protocol) относится к числу наиболее популярных протоколов и с каждым годом все сильнее вытесняет даже таких корифеев, как FTP, NNTP, POP3, SMTP, IMAP4. Современные пользователи скачивают файлы, щелкая мышкой по ссылке, участвуют в конференциях, организованных на WEB серверах, передают и принимают почту с помощью браузера. Словом, с точки зрения обывателя, Internet и WWW – слова-синонимы.
Создается впечатление, что протокол HTTP, реализующий все перечисленные выше возможности, должен быть невероятно сложным для понимания, но это совсем не так! Минимальное взаимодействие с WEB сервером обеспечивается даже при знании всего лишь одной команды!
Невероятно? Вовсе нет, - круг задач, возложенных на HTTP, ограничивается поддержкой передачей данных от сервера к клиенту и в редких случаях наоборот. Дальнейшая обработка информации не входит в его компетенцию, и этим занимается специализированное программное обеспечение.
Врезка «замечание»
В базовые задачи WEB сервера входит поддержка удаленного выполнения программ, и передача файлов в формате MIME.
Клиент же занимается отображением полученной информации (гипертекст, графика, анимация) и выполнением переданного ему программного кода (Java, Visual Basic Script).
В главах «Атака на WEB сервер» и «Атака на WEB клиента» будет показано, как и почему такая схема стала уязвима против атак.
Для подключения к HTTP серверу необходимо установить с ним TCP соединение по восьмидесятому порту (если не оговорено обратное)251.
Рисунок 18 Диалог «подключение»
Появление курсора в окне telnet клиента252 означает готовность к приему команд от пользователя. Взаимодействие осуществляется по схеме «запрос-ответ», подробное описание которой содержится в RFC 1945 и в RFC 2068, а в этой главе будут рассмотрены лишь основные моменты, впрочем, вполне достаточные для полноценного взаимодействия в WEB-сервером.
Структура запроса выглядит следующим образом:
- «Метод» «Запрашиваемый Ресурс» «Версия HTTP»
- Поле 1: значение A
- Поле 2: значение B
- ...
Если не указывать версию HTTP, ответ будет возращен в спецификации HTTP 0.9, которую обязан поддерживать каждый клиент253.
Количество и наименование полей зависят от метода и рода запроса. В простейшем случае, они могут и вовсе отсутствовать.
Метод “GET” используется для получения файлов с сервера. Если имя файла неизвестно, его можно опустить, и тогда в зависимости от настоек сервера возвратится либо содержимое файла по умолчанию, либо список файлов текущего каталога, либо сообщение об ошибке доступа.
Наглядно продемонстрировать вышесказанное позволяет следующий эксперимент. Чтобы получить главную страницу сайта “lightning.prohosting.com/~kpnc/” необходимо установить TCP соединение с узлом “lightning.prohosting.com” по восьмидесятому порту и послать серверу следующий запрос: “GET /~kpnc/”. Спустя короткий промежуток времени, сервер выдаст ответ, приведенный на копии экрана, показанной ниже, и разорвет соединение:
Рисунок 19 Ответ сервера на запрос GET /~kpnc/
Мысленно представляя себе, как бы выглядел этот HTML в окне браузера, подведем воображаемую мышь к ссылке и приготовимся кликнуть. Что произошло бы, случись это на самом деле? Интерпретатор браузера извлек бы содержимое ссылки, так называемый Uniform Recourse Identifier (сокращенно URI), и сформировал бы очередной запрос.
Врезка «замечание»
Не нужно путать URI (Uniform Recourse Identifier) и URL (Uniform Recourse Locator). Идентификатор ресурса относится к локальному серверу и может фигурировать в строках запроса. Напротив же, URL может указывать куда угодно и попытка запросить у сервера Microsoft, документ, расположенный, скажем, на ссылка скрыта ничем хорошим не кончиться.
Таким образом URL=протокол://хост/URI:порт, где URI=Имя Файла?параметры&значение 1&значение 2, то есть, URI это часть URL.
Поскольку, роль браузера нам приходится играть самостоятельно, вновь подключимся к серверу, и пошлем ему следующий запрос “GET /~kpnc/next.php HTTP/1.0”
- GET /~kpnc/next.php HTTP/1.0
- HTTP/1.1 200 OK
- Date: Thu, 13 Apr 2000 11:40:07 GMT
- Server: Apache/1.3.6 (Unix)
- Last-Modified: Thu, 13 Apr 2000 11:28:20 GMT
- ETag: "b13adc-144-38f5af54"
- Accept-Ranges: bytes
- Content-Length: 324
- Connection: close
- Content-Type: text/html