В этой второй части из цикла статей мы будем использовать HTTP прокси и узнаем больше о том, как можно использовать этот очень полезный инструмент.
В этой второй части из цикла статей мы будем использовать HTTP прокси и узнаем больше о том, как можно использовать этот очень полезный инструмент.
В предыдущей части серии об использовании HTTP прокси мы осветили некоторые вопросы, такие например, почему прокси так необходимы или почему при работе необходимо иметь запущенный снифер. В этой части в перейдём непосредственно к работе с прокси. Прочтите, чтобы уяснить, как можно использовать этот мощный инструмент.
HTTP прокси часть II.
Отлично! Мы изучили сопутствующую информацию в части первой, а сейчас настало время «взлома» web-приложения. В двух словах об инсталляции, которую я здесь использую. У меня есть web-сервер Apache с урезанной версией моего сайта, никаких специальных настроек на сервере не проводилось. SPIKE HTTP прокси запущен на WindowsXP и всё это работает на виртуальной машине VMware. Нужно также упомянуть, что запустил я SPIKE, перейдя в его директорию и выполнив runme.bat. Сделав это, я ввёл IP адрес web-сервера Apache в строчке URL браузера и получил картину, показанную на иллюстрации ниже:
Рисунок 1
Не забудьте, что вам нужно сделать некоторые изменения в настройке вашего web-клиента перед запуском SPIKE. Это было описано в первой части на случай, если вы всё же забыли это сделать. Теперь у вас на экране отображается web-сайт, что на видно на скриншоте выше, также мы можем взглянуть на сам SPIKE. Это делается вводом в URL строку браузера http://SPIKE/ Посмотрите ниже, вы должны видеть примерно то же самое у себя.
Рисунок 2
Во время написания этой статьи я столкнулся, вероятно, с глюком в SPIKE : сайты, которые я проверял при помощи этого прокси всё еще находились в памяти пользовательского интерфейса. И это после того, как я запустил файл «cleanup.bat», который, в теории, должен был подчистить все старые данные. Как бы то ни было, если вы хотите видеть такой же «чистенький» интерфейс, какой показан на рисунке выше, просто перейдите по ссылке: c:\SPIKEProxy\spkproxy\spikeProxyUI и, находясь там, удалите каталоги вручную командой rmdir /S /Q каталоги_для_удаления
Однако выходит, что это больше заложенная особенность, а не глюк – при помощи неё вы сможете провести анализ уже загруженного содержимого без подключения к сети.
Ну а теперь, поскольку вышеприведенные шаги выполнены, у нас есть чистое поле для деятельности. Так будет проще, поскольку данные, с которыми вы возможно работали ранее, не будут вам мешать. Вернёмся к использованию SPIKE. Ещё раз ссылаясь на скриншот выше, зайдём по ссылке «Delve into Dir». После этого вы увидите там три каталога, в них SPIKE хранит информацию, когда она приходит с web-сайта. Давайте заглянем в каталог «img», пользуясь той же ссылкой «Delve into Dir». Вы наверное уже заметили, что мы всё больше и больше погружаемся в данные, к которым обращались на web-сайт с сервером Apache.
В мельчайших подробностях.
Когда кликните по каталогу, вы увидите пару gif файлов и один с расширением jpeg.
Продолжим и кликнем на верхний bg3.gif при помощи «Delve into Dir» еще разок. После этого появятся несколько других опций.
Рисунок 3
Сейчас вы увидите то, что я бы назвал сердцем HTTP прокси. У нас теперь есть возможность переписывать запросы и высылать их заново. Кликните на «Print Request Info» и посмотрите, что же наш браузер отправляет web-серверу при соединении с ним для того чтобы отобразить корневую страницу сайта.
Рисунок 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” и посмотрим, что же у нас здесь. Это стандартный запрос для собственно web-страницы. Теперь нажмите на “rewrite request”. Это, как я уже говроил, один из основных компонентов HTTP прокси. Через него вы сможете изменить практически любую часть оригинального запроса к web-серверу.
Рисунок 5
Теперь берём и делаем у себя простую модификацию GET запроса, в форме что изображена на рисунке:
Измените GET на HEAD в секции “Verb”. Теперь спуститесь ниже к “Body args” и введите здесь “having some fun”. Затем просто нажмите “Submit Query”. В выводе tcpdump ниже вы заметите что SPIKE HTTP прокси действительно переписал запрос согласно нашим требованиям. Великолепно! Теперь вы уже на пути к прекрасному миру безопасности web-приложений. Пока остановимся на этом.
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 и BURP. В них я покажу реальный пример использования HTTP прокси для хакинга web-приложений. Надеюсь увидеть вас и впредь. И помните, я всегда приветствую обратную связь с читателями. До встречи!
Пройдите по шифрованной тропе информационной безопасности – подпишитесь на наш ТГ-канал!