прокси-сервер в SPIKE реальном мире компьютерной безопасности
HTTP-прокси и вы
Область компьютерной безопасности - одна из непрерывно развивающихся областей связанных с компьютерами. Не иссякает поток найденных эксплойтов то к одной, то к другой программе. И практически невозможно быть достаточно сведущим во всех областях сетевой безопасности, поэтому, исходя из природы компьютерной безопасности и ее многочисленных аспектов, необходимо выбрать собственную нишу и постараться специализироваться в ней. Одна из таких ниш, это безопасность веб-приложений в разных формах. Почему я использую выражение «в разных формах»? Потому что не все веб-приложения написаны на одном языке, также их нельзя использовать с одними и теми же конфигурационными файлами или одинаковыми бэк-эндами.
Вообще, безопасность веб-приложений - достаточно интересная область для специализации, в постоянно расширяющимся Интернете всегда будут веб- приложения с миллиардами различных применений. И эти приложения, естественно, разработаны для взаимодействия с потенциальным клиентом. Но нельзя полагать, что если лицо компании в Интернете было создано профессиональными программистами, то оно будет безупречно. Как мы знаем, зачастую получается наоборот, так как невозможно написать идеальный код, и это не зависит от используемого языка программирования.
Это приводит нас к одной из граней веб-безопасности: очень часто большое число веб-приложений написано дома, и говорить в этом случае о гарантиях качества просто не приходится. Программист, работающий в компании, будет счастлив просто вовремя закончить проект, оставляя лишь немного времени для аудита кода. Конечно, есть специализированные инструменты, позволяющие проводить анализ исходного текста, однако множество из них неприменимы из-за большого числа ложных срабатываний, а те, что можно реально использовать, почти всегда непомерно дороги.
Даже нам, людям, не имеющим прямого отношения к программированию, я думаю, можно оценить всю сложность написания качественного кода. Это становится особенно актуально, когда речь идет о программных продуктах масштаба предприятия и тысячах строк кода, из которых они состоят. Однако есть еще аспект: возможно, у отдельно взятого программиста есть прекрасное понимание жизненного цикла программы, и в то же время у компании в целом может не быть четкого понимания технического задания, согласно которому пишется код. Хотя это и не критическая составляющая, но она позволит обнаружить некоторые подводные камни в этом вопросе.
И вот программист завершает написание веб-приложения, которое было ему (или ей) поручено. Сейчас самое время заняться его тестированием и попытаться выявить все недочеты и глюки. Каков же лучший способ это сделать? Хороший вопрос! Это приводит нас обратно к названию этой статьи. Тестирование только что написанного приложения лучше всего проводить, используя HTTP-прокси. Это превосходный способ взаимодействия с веб- приложением при помощи методов, которые нельзя воссоздать при помощи обычной веб-сессии. Разработчик может перехватывать запросы клиентской части и изменять каждое поле в этих запросах, чтобы провести стресс-тест.
ближе к делу!
Надеюсь, вы не заснули до этого момента. Все-таки всегда важно выдать теорию по теме, чтобы лучше понять суть практики. HTTP-прокси, который мы рассмотрим и будем использовать, называется SPIKE. Он был написан очень талантливым человеком – Дейвом Эйтелом (Dave Aitel) из компании Immunitysec.
Вы обнаружите, что для работы SPIKE потребуется интерпретатор Python. Пожалуйста, зайдите на CPAN и загрузите оттуда исполняемый файл Python. Для этого вам потребуется указать e-mail адрес, только и всего. Еще желательно прочесть README.txt чтобы правильно настроить ваш веб-браузер. В качестве последнего шага просто запустите runme.bat. Напечатав в строке URL вашего браузера http://spike/ вы увидите SPIKE. Все, теперь мы в деле!
Теперь давайте развлечемся с веб-сервером. В нашем случае, для тестирования, я просто установил Apache на виртуальную машину VMware. Это позволить поиграть с настройками SPIKE, так сказать, в «лабораторных условиях». Никаких дополнительных манипуляций с веб-сервером не проводилось. В завершение, я установил на него урезанную версию своего собственного сайта.
время для веселья
Где бы вы ни работали, под рукой всегда должен быть какой-нибудь сниффер, запущенный в фоне. Так можно будет проверить вывод программ в случае расхождений или появления странных результатов. И наш случай не исключение. Я воспользуюсь tcpdump от MicroOLAP, который отлично работает под WindowsXP SP2. К тому же он бесплатен для домашнего использования.
Теперь, когда у нас есть работающий снифер, нужно всего-навсего скомандовать ему заносить в лог только пакеты, проходящие между машиной, на которой запущен SPIKE, и компьютером с веб-сервером Apache. Хотя это скроет часть пакетов, которые атакующий в реальности все же будет видеть. Позже вы можете запустить tcpdump для сбора только пакетов с/на 80 порт.
Отлично! Мы изучили сопутствующую информацию, а сейчас настало время «взлома» веб-приложения. Еще раз в двух словах опишу инсталляцию, которую я здесь использую. У меня есть сервер Apache с урезанной версией моего сайта, никаких специальных настроек на сервере не проводилось. SPIKE HTTP- прокси запущен на WindowsXP и все это работает на виртуальной машине VMware.
Итак, я запустил SPIKE, перейдя в его директорию и выполнив runme.bat. Сделав это, я ввел IP-адрес web-сервера Apache в строчке URL браузера и получил картину, показанную на иллюстрации 1.
Рис. 1.
Не забудьте, что вам нужно сделать некоторые изменения в настройке вашего веб-клиента перед запуском SPIKE. Теперь у вас на экране отображается веб-сайт, что на видно на скриншоте на рисунке 1. Также мы можем взглянуть на веб-консоль самого SPIKE. Это делается вводом в URL-строку браузера http://SPIKE/ Посмотрите на рис. 2, вы должны видеть примерно то же самое у себя.
Рис. 2.
Во время написания этой статьи я столкнулся, вероятно, с глюком в SPIKE : сайты, которые я проверял при помощи этого прокси все еще находились в памяти пользовательского интерфейса. И это после того, как я запустил файл «cleanup.bat», который, в теории, должен был подчистить все старые данные. Как бы то ни было, если вы хотите видеть такой же «чистенький» интерфейс, какой показан на рисунке выше, просто перейдите в директорию %systemroot%:\SPIKEProxy\spkproxy\spikeProxyUI и, находясь там, удалите каталоги вручную.
Однако выходит, что это скорее заложенная изначально фича, а не глюк – при помощи нее вы сможете провести анализ уже загруженного содержимого без подключения к сети.
Ну а теперь, поскольку вышеприведенные шаги выполнены, у нас есть чистое поле для деятельности. Так будет проще, поскольку данные, с которыми вы, возможно, работали ранее, не будут вам мешать. Вернемся к использованию SPIKE. Еще раз ссылаясь на скриншот выше, зайдем по ссылке «Delve into Dir». После этого вы увидите там три каталога, в них SPIKE хранит информацию, когда она приходит с веб-сайта. Давайте заглянем в каталог «img», пользуясь той же ссылкой «Delve into Dir». Вы, наверное, уже заметили, что мы все больше и больше погружаемся в данные, к которым обращались на веб-сайт с сервером Apache.
в мельчайших подробностях
Когда я кликнул по каталогу, я увидел пару gif-файлов и один с расширением jpeg.
Продолжим и кликнем на верхний bg3.gif при помощи «Delve into Dir» еще разок. После этого появятся несколько других опций (рис. 3.).
Рис. 3.
Сейчас вы увидите то, что я бы назвал сердцем HTTP-прокси. У нас теперь есть возможность переписывать запросы и высылать их заново. Кликните на «Print Request Info» и посмотрите, что же наш браузер отправляет веб-серверу при соединении с ним для того, чтобы отобразить корневую страницу сайта (рис. 4.).
Рис. 4.
На скриншоте (рис. 4) мы видим ровно то, что передается от клиента серверу. Сверху указаны IP-адрес сервера и порт. SSL не использовался, далее идет HTTP-запрос GET и то, какая информация запрашивается. В этом примере это «bg3.gif» и за ним адрес хоста. Следующее поле - это User-Agent – оно определяет тип клиентского браузера. Остальные поля говорят сами за себя, но если вы не уверены в их интерпретации, я бы предложил почитать какую-нибудь доку по HTTP. Есть еще одна вещь, на которую стоит обратить внимание – это поле «If-None-Match». Его значение состоит из набора цифр и букв; поле больше известно как ETag и используется при кэшировании. Значение генерируется сервером и применяется для типов данных, таких как gif и им подобных. Таким образом браузер, запрашивая что-либо, может обнаружить, что у него в кэше уже есть данная информация. У меня как раз уже есть этот gif-файл, и поэтому сервер ответил на запрос HTTP кодом 304 Not modified. Это означает что файл, который есть у меня в кэше, не изменился и на сервере, следовательно, не нужно высылать его клиенту еще раз, так как файл может быть взят из кэша на моей локальной машине. Вы можете видеть эту информацию в окне DOS с запущенным для старта SPIKE файлом «runme.bat».
Response Header:
HTTP/1.1 304 Not Modified
Date: Sun, 19 Feb 2006 16:39:55 GMT
Server: Apache/2.0.54 (Win32)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=98
ETag: "222a-ab-4096dbdf"
Теперь вернемся назад к тем трем директориям, которые мы видели ранее - img, css и _directory_. Теперь, кликая по “Delve into Dir”, зайдите в _directory_. Щелчок на “Print Request Info” - и посмотрим, что же у нас здесь. Это стандартный запрос для собственно веб-страницы. Теперь нажмите на “rewrite request”. Это, как я уже говроил, один из основных компонентов HTTP-прокси. Через него вы сможете изменить практически любую часть оригинального запроса к веб-серверу.
Рис. 5.
Теперь берем и делаем у себя простую модификацию GET запроса, в форме, что изображена на рисунке 5.
Изменим GET на HEAD в секции “Verb”. Теперь спустимся ниже к “Body args” и введем здесь “having some fun”. Затем просто нажимаем “Submit Query”. В выводе tcpdump ниже вы заметите, что SPIKE HTTP прокси действительно переписал запрос согласно нашим требованиям. Великолепно! Теперь вы уже на пути к прекрасному миру безопасности веб-приложений.
13:38:29.828125 IP (tos 0x0, ttl 128, id 6305, offset 0, flags [DF], proto: TCP
(6), length: 362) 192.168.1.108.1610 > 192.168.1.104.80: P, cksum 0xe1af (correct), 2856622211:2856622533(322) ack 3348334422 win 64240 0x0000: 4500 016a 18a1 4000 8006 5cc8 c0a8 016c E..j..@...\....l
0x0010: c0a8 0168 064a 0050 aa44 9883 c793 8756 ...h.J.P.D.....V
0x0020: 5018 faf0 e1af 0000 4845 4144 202f 2048 P.......HEAD./.H
0x0030: 5454 502f 312e 310d 0a48 6f73 743a 2031 TTP/1.1..Host:.1
0x0040: 3932 2e31 3638 2e31 2e31 3034 0d0a 5573 92.168.1.104..Us
0x0050: 6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c er-Agent:.Mozill
0x0060: 612f 342e 3020 2863 6f6d 7061 7469 626c a/4.0.(compatibl
0x0070: 653b 204d 5349 4520 352e 303b 2057 696e e;.MSIE.5.0;.Win
0x0080: 646f 7773 204e 543b 2042 6f62 290d 0a41 dows.NT;.Bob)..A
0x0090: 6363 6570 743a 2069 6d61 6765 2f67 6966 ccept:.image/gif
0x00a0: 2c20 696d 6167 652f 782d 7862 6974 6d61 ,.image/x-xbitma
0x00b0: 702c 2069 6d61 6765 2f6a 7065 672c 2069 p,.image/jpeg,.i
0x00c0: 6d61 6765 2f70 6a70 6567 2c20 2a2f 2a0d mage/pjpeg,.*/*.
0x00d0: 0a41 6363 6570 742d 4c61 6e67 7561 6765 .Accept-Language
0x00e0: 3a20 656e 2d75 730d 0a43 6f6e 6e65 6374 :.en-us..Connect
0x00f0: 696f 6e3a 204b 6565 702d 416c 6976 650d ion:.Keep-Alive.
0x0100: 0a49 662d 4d6f 6469 6669 6564 2d53 696e .If-Modified-Sin
0x0110: 6365 3a20 5361 742c 2032 3020 4175 6720 ce:.Sat,.20.Aug.
0x0120: 3230 3035 2032 303a 3235 3a35 3020 474d 2005.20:25:50.GM
0x0130: 540d 0a49 662d 4e6f 6e65 2d4d 6174 6368 T..If-None-Match
0x0140: 3a20 0d0a 436f 6e74 656e 742d 4c65 6e67 :...Content-Leng
0x0150: 7468 3a20 3136 0d0a 0d0a 6861 7669 6e67 th:.16....having
0x0160: 2b73 6f6d 652b 6675 6e3d +some+fun=
Полагаю, подготовленный читатель уже давно знает, что делать дальше. В двух словах – подбирать разнообразные каверзные сочетания заголовков запроса и собирать статистику напредмет того, насколько удачно это все отрабатывает применительно к вашему приложению.
В будущем возможно будет еще несколько статей, посвященных SPIKE, где я покажу реальный пример использования HTTP-прокси для хакинга веб- приложений.
Дон Паркер (Don Parker), GCIA,GCIH, специализируется на обнаружении атак и нештатных ситуациях
Область компьютерной безопасности - одна из непрерывно развивающихся областей связанных с компьютерами. Не иссякает поток найденных эксплойтов то к одной, то к другой программе. И практически невозможно быть достаточно сведущим во всех областях сетевой безопасности, поэтому, исходя из природы компьютерной безопасности и ее многочисленных аспектов, необходимо выбрать собственную нишу и постараться специализироваться в ней. Одна из таких ниш, это безопасность веб-приложений в разных формах. Почему я использую выражение «в разных формах»? Потому что не все веб-приложения написаны на одном языке, также их нельзя использовать с одними и теми же конфигурационными файлами или одинаковыми бэк-эндами.
Вообще, безопасность веб-приложений - достаточно интересная область для специализации, в постоянно расширяющимся Интернете всегда будут веб- приложения с миллиардами различных применений. И эти приложения, естественно, разработаны для взаимодействия с потенциальным клиентом. Но нельзя полагать, что если лицо компании в Интернете было создано профессиональными программистами, то оно будет безупречно. Как мы знаем, зачастую получается наоборот, так как невозможно написать идеальный код, и это не зависит от используемого языка программирования.
Это приводит нас к одной из граней веб-безопасности: очень часто большое число веб-приложений написано дома, и говорить в этом случае о гарантиях качества просто не приходится. Программист, работающий в компании, будет счастлив просто вовремя закончить проект, оставляя лишь немного времени для аудита кода. Конечно, есть специализированные инструменты, позволяющие проводить анализ исходного текста, однако множество из них неприменимы из-за большого числа ложных срабатываний, а те, что можно реально использовать, почти всегда непомерно дороги.
Даже нам, людям, не имеющим прямого отношения к программированию, я думаю, можно оценить всю сложность написания качественного кода. Это становится особенно актуально, когда речь идет о программных продуктах масштаба предприятия и тысячах строк кода, из которых они состоят. Однако есть еще аспект: возможно, у отдельно взятого программиста есть прекрасное понимание жизненного цикла программы, и в то же время у компании в целом может не быть четкого понимания технического задания, согласно которому пишется код. Хотя это и не критическая составляющая, но она позволит обнаружить некоторые подводные камни в этом вопросе.
И вот программист завершает написание веб-приложения, которое было ему (или ей) поручено. Сейчас самое время заняться его тестированием и попытаться выявить все недочеты и глюки. Каков же лучший способ это сделать? Хороший вопрос! Это приводит нас обратно к названию этой статьи. Тестирование только что написанного приложения лучше всего проводить, используя HTTP-прокси. Это превосходный способ взаимодействия с веб- приложением при помощи методов, которые нельзя воссоздать при помощи обычной веб-сессии. Разработчик может перехватывать запросы клиентской части и изменять каждое поле в этих запросах, чтобы провести стресс-тест.
ближе к делу!
Надеюсь, вы не заснули до этого момента. Все-таки всегда важно выдать теорию по теме, чтобы лучше понять суть практики. HTTP-прокси, который мы рассмотрим и будем использовать, называется SPIKE. Он был написан очень талантливым человеком – Дейвом Эйтелом (Dave Aitel) из компании Immunitysec.
Вы обнаружите, что для работы SPIKE потребуется интерпретатор Python. Пожалуйста, зайдите на CPAN и загрузите оттуда исполняемый файл Python. Для этого вам потребуется указать e-mail адрес, только и всего. Еще желательно прочесть README.txt чтобы правильно настроить ваш веб-браузер. В качестве последнего шага просто запустите runme.bat. Напечатав в строке URL вашего браузера http://spike/ вы увидите SPIKE. Все, теперь мы в деле!
Теперь давайте развлечемся с веб-сервером. В нашем случае, для тестирования, я просто установил Apache на виртуальную машину VMware. Это позволить поиграть с настройками SPIKE, так сказать, в «лабораторных условиях». Никаких дополнительных манипуляций с веб-сервером не проводилось. В завершение, я установил на него урезанную версию своего собственного сайта.
время для веселья
Где бы вы ни работали, под рукой всегда должен быть какой-нибудь сниффер, запущенный в фоне. Так можно будет проверить вывод программ в случае расхождений или появления странных результатов. И наш случай не исключение. Я воспользуюсь tcpdump от MicroOLAP, который отлично работает под WindowsXP SP2. К тому же он бесплатен для домашнего использования.
Теперь, когда у нас есть работающий снифер, нужно всего-навсего скомандовать ему заносить в лог только пакеты, проходящие между машиной, на которой запущен SPIKE, и компьютером с веб-сервером Apache. Хотя это скроет часть пакетов, которые атакующий в реальности все же будет видеть. Позже вы можете запустить tcpdump для сбора только пакетов с/на 80 порт.
Отлично! Мы изучили сопутствующую информацию, а сейчас настало время «взлома» веб-приложения. Еще раз в двух словах опишу инсталляцию, которую я здесь использую. У меня есть сервер Apache с урезанной версией моего сайта, никаких специальных настроек на сервере не проводилось. SPIKE HTTP- прокси запущен на WindowsXP и все это работает на виртуальной машине VMware.
Итак, я запустил SPIKE, перейдя в его директорию и выполнив runme.bat. Сделав это, я ввел IP-адрес web-сервера Apache в строчке URL браузера и получил картину, показанную на иллюстрации 1.
Рис. 1.
Не забудьте, что вам нужно сделать некоторые изменения в настройке вашего веб-клиента перед запуском SPIKE. Теперь у вас на экране отображается веб-сайт, что на видно на скриншоте на рисунке 1. Также мы можем взглянуть на веб-консоль самого SPIKE. Это делается вводом в URL-строку браузера http://SPIKE/ Посмотрите на рис. 2, вы должны видеть примерно то же самое у себя.
Рис. 2.
Во время написания этой статьи я столкнулся, вероятно, с глюком в SPIKE : сайты, которые я проверял при помощи этого прокси все еще находились в памяти пользовательского интерфейса. И это после того, как я запустил файл «cleanup.bat», который, в теории, должен был подчистить все старые данные. Как бы то ни было, если вы хотите видеть такой же «чистенький» интерфейс, какой показан на рисунке выше, просто перейдите в директорию %systemroot%:\SPIKEProxy\spkproxy\spikeProxyUI и, находясь там, удалите каталоги вручную.
Однако выходит, что это скорее заложенная изначально фича, а не глюк – при помощи нее вы сможете провести анализ уже загруженного содержимого без подключения к сети.
Ну а теперь, поскольку вышеприведенные шаги выполнены, у нас есть чистое поле для деятельности. Так будет проще, поскольку данные, с которыми вы, возможно, работали ранее, не будут вам мешать. Вернемся к использованию SPIKE. Еще раз ссылаясь на скриншот выше, зайдем по ссылке «Delve into Dir». После этого вы увидите там три каталога, в них SPIKE хранит информацию, когда она приходит с веб-сайта. Давайте заглянем в каталог «img», пользуясь той же ссылкой «Delve into Dir». Вы, наверное, уже заметили, что мы все больше и больше погружаемся в данные, к которым обращались на веб-сайт с сервером Apache.
в мельчайших подробностях
Когда я кликнул по каталогу, я увидел пару gif-файлов и один с расширением jpeg.
Продолжим и кликнем на верхний bg3.gif при помощи «Delve into Dir» еще разок. После этого появятся несколько других опций (рис. 3.).
Рис. 3.
Сейчас вы увидите то, что я бы назвал сердцем HTTP-прокси. У нас теперь есть возможность переписывать запросы и высылать их заново. Кликните на «Print Request Info» и посмотрите, что же наш браузер отправляет веб-серверу при соединении с ним для того, чтобы отобразить корневую страницу сайта (рис. 4.).
Рис. 4.
На скриншоте (рис. 4) мы видим ровно то, что передается от клиента серверу. Сверху указаны IP-адрес сервера и порт. SSL не использовался, далее идет HTTP-запрос GET и то, какая информация запрашивается. В этом примере это «bg3.gif» и за ним адрес хоста. Следующее поле - это User-Agent – оно определяет тип клиентского браузера. Остальные поля говорят сами за себя, но если вы не уверены в их интерпретации, я бы предложил почитать какую-нибудь доку по HTTP. Есть еще одна вещь, на которую стоит обратить внимание – это поле «If-None-Match». Его значение состоит из набора цифр и букв; поле больше известно как ETag и используется при кэшировании. Значение генерируется сервером и применяется для типов данных, таких как gif и им подобных. Таким образом браузер, запрашивая что-либо, может обнаружить, что у него в кэше уже есть данная информация. У меня как раз уже есть этот gif-файл, и поэтому сервер ответил на запрос HTTP кодом 304 Not modified. Это означает что файл, который есть у меня в кэше, не изменился и на сервере, следовательно, не нужно высылать его клиенту еще раз, так как файл может быть взят из кэша на моей локальной машине. Вы можете видеть эту информацию в окне DOS с запущенным для старта SPIKE файлом «runme.bat».
Response Header:
HTTP/1.1 304 Not Modified
Date: Sun, 19 Feb 2006 16:39:55 GMT
Server: Apache/2.0.54 (Win32)
Connection: Keep-Alive
Keep-Alive: timeout=15, max=98
ETag: "222a-ab-4096dbdf"
Теперь вернемся назад к тем трем директориям, которые мы видели ранее - img, css и _directory_. Теперь, кликая по “Delve into Dir”, зайдите в _directory_. Щелчок на “Print Request Info” - и посмотрим, что же у нас здесь. Это стандартный запрос для собственно веб-страницы. Теперь нажмите на “rewrite request”. Это, как я уже говроил, один из основных компонентов HTTP-прокси. Через него вы сможете изменить практически любую часть оригинального запроса к веб-серверу.
Рис. 5.
Теперь берем и делаем у себя простую модификацию GET запроса, в форме, что изображена на рисунке 5.
Изменим GET на HEAD в секции “Verb”. Теперь спустимся ниже к “Body args” и введем здесь “having some fun”. Затем просто нажимаем “Submit Query”. В выводе tcpdump ниже вы заметите, что SPIKE HTTP прокси действительно переписал запрос согласно нашим требованиям. Великолепно! Теперь вы уже на пути к прекрасному миру безопасности веб-приложений.
13:38:29.828125 IP (tos 0x0, ttl 128, id 6305, offset 0, flags [DF], proto: TCP
(6), length: 362) 192.168.1.108.1610 > 192.168.1.104.80: P, cksum 0xe1af (correct), 2856622211:2856622533(322) ack 3348334422 win 64240 0x0000: 4500 016a 18a1 4000 8006 5cc8 c0a8 016c E..j..@...\....l
0x0010: c0a8 0168 064a 0050 aa44 9883 c793 8756 ...h.J.P.D.....V
0x0020: 5018 faf0 e1af 0000 4845 4144 202f 2048 P.......HEAD./.H
0x0030: 5454 502f 312e 310d 0a48 6f73 743a 2031 TTP/1.1..Host:.1
0x0040: 3932 2e31 3638 2e31 2e31 3034 0d0a 5573 92.168.1.104..Us
0x0050: 6572 2d41 6765 6e74 3a20 4d6f 7a69 6c6c er-Agent:.Mozill
0x0060: 612f 342e 3020 2863 6f6d 7061 7469 626c a/4.0.(compatibl
0x0070: 653b 204d 5349 4520 352e 303b 2057 696e e;.MSIE.5.0;.Win
0x0080: 646f 7773 204e 543b 2042 6f62 290d 0a41 dows.NT;.Bob)..A
0x0090: 6363 6570 743a 2069 6d61 6765 2f67 6966 ccept:.image/gif
0x00a0: 2c20 696d 6167 652f 782d 7862 6974 6d61 ,.image/x-xbitma
0x00b0: 702c 2069 6d61 6765 2f6a 7065 672c 2069 p,.image/jpeg,.i
0x00c0: 6d61 6765 2f70 6a70 6567 2c20 2a2f 2a0d mage/pjpeg,.*/*.
0x00d0: 0a41 6363 6570 742d 4c61 6e67 7561 6765 .Accept-Language
0x00e0: 3a20 656e 2d75 730d 0a43 6f6e 6e65 6374 :.en-us..Connect
0x00f0: 696f 6e3a 204b 6565 702d 416c 6976 650d ion:.Keep-Alive.
0x0100: 0a49 662d 4d6f 6469 6669 6564 2d53 696e .If-Modified-Sin
0x0110: 6365 3a20 5361 742c 2032 3020 4175 6720 ce:.Sat,.20.Aug.
0x0120: 3230 3035 2032 303a 3235 3a35 3020 474d 2005.20:25:50.GM
0x0130: 540d 0a49 662d 4e6f 6e65 2d4d 6174 6368 T..If-None-Match
0x0140: 3a20 0d0a 436f 6e74 656e 742d 4c65 6e67 :...Content-Leng
0x0150: 7468 3a20 3136 0d0a 0d0a 6861 7669 6e67 th:.16....having
0x0160: 2b73 6f6d 652b 6675 6e3d +some+fun=
Полагаю, подготовленный читатель уже давно знает, что делать дальше. В двух словах – подбирать разнообразные каверзные сочетания заголовков запроса и собирать статистику напредмет того, насколько удачно это все отрабатывает применительно к вашему приложению.
В будущем возможно будет еще несколько статей, посвященных SPIKE, где я покажу реальный пример использования HTTP-прокси для хакинга веб- приложений.
Дон Паркер (Don Parker), GCIA,GCIH, специализируется на обнаружении атак и нештатных ситуациях
Сетевые решения. Статья была опубликована в номере 12 за 2006 год в рубрике лабораторная работа
