HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Как анализировать POST запросы в веб-браузере
Современные веб-сайты становятся всё сложнее, используют всё больше библиотек и веб технологий. Для целей отладки разработчиками сложных веб-сайтов и веб-приложений потребовались новые инструменты. Ими стали «Инструменты разработчика» интегрированные в сами веб-браузеры:
- Chrome DevTools
- Firefox Developer Tools
Они по умолчанию поставляются с браузерами (Chrome и Firefox) и предоставляют много возможностей по оценке и отладке сайтов для самых разных условий. К примеру, можно открыть сайт или запустить веб-приложение как будто бы оно работает на мобильном устройстве, или симулировать лаги мобильных сетей, или запустить сценарий ухода приложения в офлайн, можно сделать скриншот всего сайта, даже для больших страниц, требующих прокрутки и т.д. На самом деле, Инструменты разработчика требуют глубокого изучения, чтобы по-настоящему понять всю их мощь.
В предыдущих статьях я уже рассматривал несколько практических примеров использования инструментов DevTools в браузере:
- Статический анализ исходного кода веб-сайта в браузере
- Анализ динамически генерируемых с помощью JavaScript сайтов и сайтов с подгружаемым контентом (поиск ссылок на видео, изображения, на подгружаемый контент)
Эта небольшая заметка посвящена анализу POST запросов. Мы научимся просматривать отправленные методом POST данные прямо в самом веб-браузере. Научимся получать их в исходном («сыром») виде, а также в виде значений переменных.
Я буду показывать на примере сайта http://spys.one/en/free-proxy-list/ из статьи про прокси. (На самом деле, это простейший пример — в качестве более сложных примеров, попробуйте самостоятельно разобраться, например, в POST GMail при открытии и других действий с письмами).
По фрагменту исходного кода страницы видно, что данные из формы передаются методом POST, причём используется конструкция onChange=»this.form.submit();»:
Несмотря на необычность решения — отсутствует кнопка «Отправить», а отправка данных происходит при любом изменении поля , это вполне простой пример, поддающийся анализу статичного кода — то есть можно собрать имена всех ‘ов, собрать их значения и составить строку. Но я предлагаю познакомиться с намного более быстрым способом анализа.
Как увидеть данные, переданные методом POST, в Google Chrome
Итак, открываем (или обновляем, если она уже открыта) страницу, от которой мы хотим узнать передаваемые POST данные. Теперь открываем инструменты разработчика (в предыдущих статьях я писал, как это делать разными способами, например, я просто нажимаю F12):
Теперь отправляем данные с помощью формы.
Переходим во вкладку «Network» (сеть), кликаем на иконку «Filter» (фильтр) и в качестве значения фильтра введите method:POST:
Как видно на предыдущем скриншоте, был сделан один запрос методом POST, кликаем на него:
- Header — заголовки (именно здесь содержаться отправленные данные)
- Preview — просмотр того, что мы получили после рендеренга (это же самое показано на странице сайта)
- Response — ответ (то, что сайт прислал в ответ на наш запрос)
- Cookies — кукиз
- Timing — сколько времени занял запрос и ответ
Поскольку нам нужно увидеть отправленные методом POST данные, то нас интересует столбец Header.
Там есть разные полезные данные, например:
- Request URL — адрес, куда отправлена информация из формы
- Form Data — отправленные значения
Пролистываем до Form Data:
Там мы видим пять отправленных переменных и из значения.
Если нажать «view source», то отправленные данные будут показаны в виде строки:
xpp=5&xf1=0&xf2=0&xf4=0&xf5=0
Вид «view parsed» — это вид по умолчанию, в котором нам в удобном для восприятия человеком виде показаны переданные переменные и их значения.
Как увидеть данные, переданные методом POST, в Firefox
В Firefox всё происходит очень похожим образом.
Открываем или обновляем нужную нам страницу.
Открываем Developer Tools (F12).
Отправляем данные из формы.
Переходим во вкладку «Сеть» и в качестве фильтра вставляем method:POST:
Кликните на интересующий вас запрос и в правой части появится окно с дополнительной информацией о нём:
Переданные в форме значения вы увидите если откроете вкладку «Параметры»:
Если вы хотите получить отправленные данные в виде строки, то вернитесь во вкладку «Заголовки» и нажмите кнопку «Изменить и снова отправить», в открывшейся области пролистните до «Тело запроса»:
Как вы уже поняли, здесь не только можно скопировать строку POST, но и отредактировать её и отправить запрос заново.
Другие фильтры инструментов разработчика
Для Chrome кроме уже рассмотренного method:POST доступны следующие фильтры:
Связанные статьи:
- Анализ динамически генерируемых с помощью JavaScript сайтов и сайтов с подгружаемым контентом (поиск ссылок на видео, изображения, на подгружаемый контент) (88.2%)
- lulzbuster – инструмент для быстрого поиска скрытых файлов и папок на сайтах (62.3%)
- Статический анализ исходного кода веб-сайта в браузере (60.3%)
- Аудит безопасности роутера SKYWORTH GN542VF — взламываем пароль не выходя из веб-браузера! (59.9%)
- Как использовать User Agent для атак на сайты (57.5%)
- Получение имён пользователей сайта методом перебора (RANDOM — 50.4%)
факультете информационной безопасности от GeekBrains? Комплексная годовая программа практического обучения с охватом всех основных тем, а также с дополнительными курсами в подарок. По итогам обучения выдаётся свидетельство установленного образца и сертификат. По этой ссылке специальная скидка на любые факультеты и курсы!
Как проверить HTTP-запрос типа POST, если серверного скрипта пока нет?
При нажатии на кнопку наблюдаю в девтулзах (на вкладке «Сеть») отправление запроса типа GET (!). Прошу помочь разобраться — почему. И — есть ли способ посмотреть тело запроса типа POST, не имея серверного скрипта. Предполагаю, что всё дело в значении атрибута «action», но — повторюсь — бэкенда пока нет. А запрос проверить очень нужно.
Отслеживать
задан 15 дек 2020 в 8:14
11 2 2 бронзовых знака
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Апач при POST-запросе на URL папки без конечного слеша, перенаправляет на URL со слешем и при этом запрос трансформируется в GET. Если же слеш поставить, то эффект пропадает.
Вывод: В action формы ставьте всегда слеш в конце URL папки, а лучше используйте URL файла.
Отслеживать
ответ дан 15 дек 2020 в 8:26
71 10 10 бронзовых знаков
Да, я это читал, спасибо. Проблема в том, что скрипта, принимающего запрос, у меня нет. Можно ли как-то без скрипта добится, чтобы «POST» был именно «POST»? Может фиктивные или тренировочные сервера есть какие-нибудь? Чей адрес я мог бы просто для эксперимента поставить?
Home
Сегодня мы рассмотрим POST-запросы. Они, пожалуй, наиболее важные из всех REST-запросов, потому что добавляют новые записи в базу данных приложения. Очень важно как следует их протестировать, потому что они напрямую влияют на качество данных вашей базы.
Чтобы разобраться с POST-запросами, мы снова обратимся к Swagger Pet Store и Postman. Перейдите в Pet Store (http://petstore.swagger.io) и кликните на первом POST-запросе к «/pet». Этот POST-запрос добавит питомца в магазин. Посмотрите на Example Value (примеры значений):
Это тело POST-запроса. В отличие от GET-запросов, у которых обычно нет тела, в POST вы, как правило, найдете json или xml. Тело запроса – это данные, которые вы добавляете в базу данных. Кликните по ссылке Model:
Это окно вкратце описывает, что за значения используются в теле запроса. Вы можете нажимать на иконки «>», чтобы раскрыть каждую секцию модели. С моей точки зрения, она расплывчато описывает, что такое категория и тэги, поэтому мне придется поиграть в угадайку. Давайте пройдемся по каждой секции модели Pet:
- id: это id питомца, который можно использовать в GET-запросах, которые мы уже рассматривали.
- category: описывает, к какому виду принадлежит питомец. Id – уникальный идентификатор категории, а name – слово, описывающее животное.
- name: имя питомца.
- photoUrls: строки-ссылки на изображения питомца.
- tags: описания, которые можно добавить к питомцу. Id – уникальный идентификатор тэга, а name – слово, описывающее питомца.
- status: статус питомца в магазине. Может быть available (доступен), pending (забронирован) или sold (продан).
Мы можем использовать информацию в модели, чтобы создать POST-запрос на добавление нового питомца. Нажмите на «Try it out» и замените тело запроса следующей информацией:
< "id": 102, "category": < "id": 1, "name": "cat" >, "name": "Grumpy Cat", "photoUrls": [ "https://pbs.twimg.com/profile_images/948294484596375552/RyGNqDEM_400x400.jpg" ], "tags": [ < "id": 1, "name": "blue eyes" >], "status": "sold" >
Перед тем, как нажать на Execute, обратите внимание, что кое-что в этом POST-запросе отличается от того, с чем вы столкнетесь в ваших приложениях. Обычно при публикации объекта с id, который уже существует в базе данных, вы получите сообщение, что запись уже имеется. В случае Pet Store, если id уже есть, запись будет перезаписана данными, отправленными вами.
Теперь нажимаем на «Execute». Взгляните, что вернулось в теле ответа. Вы должны увидеть данные, которые вы добавили. Они могут отличаться порядком от тела запроса, но это не важно.
Давайте убедимся, что новый питомец действительно добавлен! Вернитесь к запросу GET pet/, откройте его и нажмите «Try it out». Введите 100 в поле ID, и нажмите на «Execute». Вы должны увидеть добавленного вами питомца в теле ответа.
Мы успешно создали запрос в Swagger, теперь давайте попробуем прогнать его в Postman. Откройте приложение и нажмите на кнопку с плюсиком «+» для создания нового запроса. Щелкните по иконке выпадающего списка рядом со словом GET, и выберите POST. Введите URL запроса: http://petstore.swagger.io/v2/pet. Нажмите на вкладку «Body» под URL и выберите опцию «Raw». В секции тела запроса ниже вставьте запрос, который мы ранее использовали в Swagger. Возможно, вам захочется его слегка изменить, поменяв id или имя питомца.
Перед тем, как отправить этот запрос через Postman, нам нужно выполнить еще одно действие – добавить заголовок. Заголовки используются в HTTP-запросах и ответах для передачи дополнительной информации серверу. В этом случае нам нужно сказать серверу, какого типа содержимого ему ожидать. Кликните на вкладке «Header» под URL, и в поле под «Key» введите «Content-Type». В поле под «Value» введите «application/json». Таким образом мы сообщаем серверу, что ему нужно искать тело запроса в json-формате. Теперь нажмите на кнопку «Send». В нижней половине окна Postman вы должны увидеть код ответа 200 и тело ответа, совпадающее с добавленными вами данными. Теперь вы можете использовать GET-запрос, чтобы убедиться, что ваш питомец добавлен.
Мы уже обсуждали тестирование форм, и тут то же самое – POST-запросы можно тестировать массой различных сценариев. Во-первых, нам надо протестировать сценарии «счастливого пути». Попробуйте отправить POST-запросы, варьируя id, категорию питомца и ее id, имя питомца, ссылки на фото, тэги и их id, и статусы питомца. Вам нужно протестировать все три статуса: sold, available и pending. Также стоит обратить внимание, что можно передавать несколько ссылок на фото, и несколько тэгов. Вот пример тела POST-запроса, где передаются три фотографии и два тэга:
< "id": 102, "category": < "id": 2, "name": "dog" >, "name": "Snoopy", "photoUrls": [ "https://schulzmuseum.org/wp-content/uploads/2017/06/920608_FlyingAce-200.jpg", "https://www.calmuseums.org/images/snoopy/snoopy.png", "https://vignette.wikia.nocookie.net/peanuts/images/2/28/AmigosperdemoSono.png/revision/latest?cb=20110823202539" ], "tags": [ < "id": 2, "name": "beagle" >, < "id": 3, "name": "flying ace" >], "status": "available" >
Теперь, когда вы протестировали ряд успешных сценариев, время задуматься о том, как можно сломать наш запрос. Во-первых, вы могли заметить по модели в Swagger, что обязательными будут только два поля: имя питомца и ссылка на фото. Что будет, если передавать только эти поля?
Мы получили ответ 200, и питомец добавлен с ID, который можно использовать, чтобы получить данные о нем. А что будет, если в теле запроса нет данных? А если нет одного из обязательных полей? Настала пора экспериментировать, передавая в запросе различные комбинации полей.
Здесь стоит отметить, что вы можете получить ответ 500 практически на любое спровоцированное вами ошибочное условие. В реальном приложении вы будете получать более точные коды ошибок и более внятные сообщения о них.
Затем стоит взглянуть на передачу нескольких ссылок и тэгов. Сколько ссылок можно передать, прежде чем начнутся ошибки? Сколько тэгов допускается передавать?
Теперь мы посмотрим на границы значений, которые мы отдаем. К примеру, что произойдет, если создать питомца с id 0? А если id будет -100000? А если id будет «FOO» или $%^? Вы можете тестировать эти значения на всех ID: питомца, категории и тэга. Насколько длинными могут быть строки? А насколько короткими? Есть ли недопустимые символы? Стоит протестировать верхние и нижние границы строк и убедиться, что запрещенные символы не принимаются сервером. Это также неплохая возможность проверить на SQL-инъекции и внедрение сценариев. К примеру, можно попробовать передать что-то вроде:
' or 1 = 1--
и посмотреть, разрешено ли это. В случае с PetStore это, скорее всего, разрешается, но реальное приложение должно запрещать такой ввод или как минимум делать его неэффективным.
Еще стоит задуматься о тестировании списка значений статуса питомца. Статус может быть одним из трех: available, pending, sold. Что произойдет, если вы передадите в статусе другое слово, число, символ? Что будет, если вы передадите статус в верхнем регистре, или если некоторые буквы будут записаны в нем? POST-запросы, как правило, нечувствительны к регистру. Стоит также проверить URL фотографии и убедиться, что в нем нельзя передать вредоносные скрипты, а также то, что не является URL.
Закончив тестировать тело запроса, переходите к заголовкам. Этому конкретному POST-запросу требуется заголовок Content-Type, позволяющий или application/json, или application/xml значение. Если заголовок отсутствует, вы получите 415 ошибку. При использовании application/xml значения вы получите ошибку 400, если только не измените тело запроса на XML-формат. Вы также можете протестировать отправку xml-тела с заголовком application/json.
И, наконец, можно протестировать URL самого запроса и его тип. Что будет, если вы сделаете запрос через https? А если измените POST на GET?
Если вкратце, есть множество способов тестирования POST-запросов, множество из которых недоступны через интерфейс. В дополнение к тестированию обязательных и необязательных полей и их валидации, вы можете также манипулировать переданным в базу объектом, заголовками, и URL запроса.
Больше информации по этой теме вы можете получить в курсе Тестирование REST API
Предыдущие статьи на эту тему
Как проверить отсылаемый POST запрос через Online сервис?
Arduino использует EtherCard.h билиотеку для отправки POST запросов. Для отладки правильности POST запроса ищу online сервис на который можно отправлять POST запрос с последующим его отображением и, возможно, анализом на ошибки.
Существует ряд решений помогающие сформировать POST запроса (вот примеры), а вот сервиса для проверки получения запроса, я к сожалению не нашел.
возможно есть решения, внутри браузера.
- Вопрос задан более трёх лет назад
- 8956 просмотров