Автор: Leonid Filatov
Эксклюзивно для форума: xss.pro
Часть: [1/3]
Ссылка на вторую статью: xss.pro/threads/125492/
Ссылка на третью статью: xss.pro/threads/125906/
Серия уроков будет разбита на две статьи.
В моих статьях мы поймём как и где ловить HTTP запросы, рассмотрим как с помощью Open Bullet можно написать Brute/Checker с помощью HTTP запросов на сайтах, где есть защита в виде CSRF токена.
Научимся находить CSRF токен, парсить его и использовать для авторизации на сайте.
Хочу сразу сказать, что я не являюсь профессионалом в этом деле. Я не программист от слова совсем, без помощи ChatGPT мной небыло написано ни одной строчки кода, но это не мешает мне делать бруты под конторы, которые меня интересуют. Но ведь в этом и вся прелесть, что нам даже не нужно знать языки программирования, чтобы написать свой брут на какой-либо сервис, я полностью за NO CODE! Ведь зачем нужно кодить, если можно не кодить, верно?
В этих статьях я просто хочу передать свой опыт, если вы делаете как-то по другому, или же у вас есть советы, то я буду рад увидеть и изучить ваши сообщения в данной теме!
Первая статья больше для новичков, но возможно и некоторые опытные пользователи для себя что-то подчеркнут. Помните, что для каждого сайта чаще всего нужен свой подход, но эта информация поможет вам понять самую БАЗУ и что в принципе нужно делать при создании брута/чекера.
Первым делом я всегда нахожу отдельную/альтернативную страницу входа на сайт, так будет проще работать, потому что в запросах будет меньше мусора (просто будет меньше подгружать картинок, скриптов и т.д.).
В этом мне помогают Google Dorks (они же дорки).
В нашем случае я буду использовать дорк:
Результат:
Мы успешно нашли страницу авторизации.
В поле site:"" можете подставлять любой свой целевой сайт и он скорее всего найдёт отдельную страницу входа (если она вообще существует, у некоторых сайтов просто нет такой ОТДЕЛЬНОЙ страницы)
С помощью этого способо я ни один раз находил альтернативные способы авторизации, потому что глупый админ на сайте с посещалкой от 1КК просто забывал выключить и убрать из выдачи, например, старую страницу авторизации где нет защиты, НО ОНА ПРИ ЭТОМ ВСЁ ЕЩЁ РАБОТАЛА! Поэтому всегда старайтесь эксперементировать с дорками, иногда это приносит свои плоды, мой дорк выше НЕ ЯВЛЯЕТСЯ УНИВЕРСАЛЬНЫМ.
Как мы видим таким образом я открыл сетевой монитор, чтобы отслеживать и анализировать HTTP запросы, которые наш браузер отправляет сайту и ответы, которые наш браузер получает от сайта.
Теперь давайте попробуем ввести в поля "Email" и "Password" какие-нибудь случайные данные и нажать на кнопку входа (SIGN IN), при этом сетевой монитор должен быть открыт!
После нажатия на кнопку входа в аккаунт, как и ожидалось, мы не вошли в аккаунт, но на данном этапе нам это и не нужно. Зато мы получили в сетевом мониторе информацию, которая гласит следующее:
Когда мы нажимаем на кнопку входа, то сайт отправляет POST запрос на адрес "www.cpooutlets.com/Account-Login?rurl=1"
Чаще всего нас будут интересовать только вкладки "Headers", "Request" и "Response". Давайте разберем каждую из них и выпишем всю необходимую информацию для формирования запроса.
ВКЛАДКА "HEADERS"
В данном разделе мы можем найти следующую информацию:
1. Ссылку, на которую отправляется POST запрос. (А именно )
2. Версию HTTP, которая используется при отправке POST запроса, а именно HTTP/2
3. Необходимые заголовки, которые от нас требует сайт при отправке запроса. (Вкладка Request Headers). Рекомендую ставить галочку в поле "Raw" напротив "Request Headers" как на скриншоте, так удобнее скопировать необходимые заголовки.
Request Headers — это как записка, которую ты отправляешь вместе с сообщением. В записке ты рассказываешь сайту важные вещи, например, какое у тебя устройство (ПК, или телефон), каким "языком" ты говоришь и как сайт должен прочитать твои данные. Это помогает сайту правильно понять и ответить на твой запрос.
4. Во вкладке "Requst Headers" есть такая строка как "Content-Type". В нашем случае там написано "application/x-www-form-urlencoded".
Типы данных в Content-Type для POST запроса — это как разные упаковки для того, что мы отправляем сайту.
Самые распространённые типы:
application/x-www-form-urlencoded — форма, где данные идут как текст.
multipart/form-data — для отправки файлов (например, картинок).
application/json — данные отправляются как текст в виде списка или таблицы.
Эти "упаковки" помогают сайту понять, в каком формате ему нужно принять данные.
Все эти данные будут нужны для корректного построения POST запроса при создании конфига в OpenBullet. Это мы будем делать во втором уроке, сейчас мы пока просто проводим разведку нашей цели.
ВКЛАДКА "REQUEST"
В данном разделе конкретно в этом случае мы можем найти содержимое нашего POST запроса, которое включает в себя следующее:
1. Наш электронную почту в поле "loginEmail"
2. Наш пароль в поле "loginPassword"
3. Защита в виде CSRF токена, который динамически генерируется сайтом перед тем, как человек нажмёт на кнопку входа. Его мы видим в поле "csrf_token"
CSRF токен — это специальный секретный код, который сайт добавляет в POST запросы. Он помогает убедиться, что запрос действительно сделан пользователем, а не кем-то посторонним.
Как это работает: когда ты заполняешь форму на сайте, сайт добавляет этот код в запрос. Когда сервер получает запрос, он проверяет этот код. Если его нет или он неправильный, сервер понимает, что это может быть атака, и отклоняет запрос. Это защищает от того, чтобы злоумышленники не отправили запрос от твоего имени без твоего согласия.
Таким образом, если бы на сайте небыло CSRF токена, нам бы было достаточно иметь только Email и Password, чтобы отправить POST запрос и получить корректный ответ от сервера. Но так как он есть, то без него мы просто получим в ответ ошибку от сайта. Во второй статье мы проверим это на практике.
В этой (первой) статье чуть позже мы уже научимся находить CSRF токен для того, чтобы потом использовать его и успешно отправлять POST запросы. Но в этом уроке мы найдём его вручную, чтобы понять принцип, а потом уже во втором уроке автоматизируем этот процесс.
Так же хочу добавить, что мы уже поняли из Content-Type во вкладке HEADERS (см. выше), что при отправке POST запроса у нас использутся формат данных application/x-www-form-urlencoded.
Давайте нажмём галочку "Raw" во вкладке "Request" и посмотрим, как содержимое нашего запроса выглядит на самом деле:
А именно:
Как мы видим наши данные самую малость закодированы, например почта выглядит как "leonidfilatov%40gmail.com", а должна быть "leonidfilatov@gmail.com".
Давайте раскодируем наши данные, так будет удобнее строить запрос в будущем:
1. Просто идём на сайт urldecoder.org
2. Вставляем содержимое нашего запроса в поле ввода, жмём "Decode" и получаем результат.
Мы получили:
Запишем эти данные и перейдём к следующей вкладке.
ВКЛАДКА "RESPONSE"
В этой вкладке мы можем увидеть какие данные сервер отправил нам в своём ОТВЕТЕ на наш POST запрос и в каком формате приходит этот ответ. Так же нажимаем "Raw", чтобы увидеть настоящий вид ответа от сайта.
Как мы можем увидеть - сайт отвечает нам в формате JSON. Так же в "error": мы можем увидеть сообщение, которое выходит при неудачной попытке входа в аккаунт, если логин и пароль НЕ ЯВЛЯЮТСЯ валидной комбинацией.
Во второй статье мы будем использовать этот ответ от сервера, чтобы определить аккаунт как "BAD".
Про вкладку "Headers" и "Request" объяснять смысла нет, потому что там по сути осталось всё тоже самое, что и в пункте 2.1.
А вот вкладка "Response" будет отличаться, ведь мы УСПЕШНО ВОШЛИ в аккаунт.
Я думаю вы заметили, что ответ изменился. У нас больше нет "error", зато появились "success": true и "redirectUrl": "/Account?Registration=false"
Таким образом сайт сообщил нам, что мы УСПЕШНО вошли в аккаунт.
Во второй статье мы будем использовать этот ответ от сервера, чтобы определить аккаунт как "GOOD" и продолжить с него парсинг всей информации (кредитные карты, имя, адрес, заказы).
И так же я уже сказал, что токен генерируется ДИНАМИЧЕСКИ при каждом заходе на страницу.
По сути исходя из этой информации мы уже можем сделать вывод, что для получения CSRF токена нужно просто сделать GET запрос на страницу, на которой находится форма авторизации.
В нашем случае это: "https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show"
1. Открываем пустую вкладку браузера, открываем сетевой монитор (см. этап 2)
2. Вставляем в адресную строку нашу ссылку на страницу авторизации
3. Переходим по ссылке и видим, что в нашем сетевом мониторе появися GET запрос на страницу, которую мы открыли.
4. Смотрим содержимое вкладки "Response", чтобы посмотреть содержимое, которое мы получили от сайта в результате нашего GET запроса.
Отлично, мы получили ответ в виде HTML страницы, теперь нам нужно посмотреть исходный код этой HTML страницы.
5. Как обычно жмём "Raw", чтобы посмотреть настоящий вид данных (в нашем случае код страницы HTML).
Потом жмём CTRL + A, чтобы выбрать весь код и копируем его для удобства в .txt файл, я буду использовать удобный редактор Notepad++.
После того как скопировали код в Notepad++, жмем CTRL+F и вводим в поле "Найти" значение "CSRF", после чего жмем на кнопку поиска.
В нашем случае токен нашёлся сразу, без каких либо заморочек. В данном случае он находится в значении value="hJKUCe........"
На некоторых сайтах он не будет находится настолько легко. Он может быть подписан просто как "token", либо же ещё как-нибудь. Но как показывает практика почти на всех сайтах он спокойно ищется по "CSRF".
Иногда может быть, что в коде страницы будет находится сразу ДВА CSRF токена, обычно я просто пробую подставить в запрос сначала первый, то есть самый верхний CSRF токен (что в 90% случаев срабатывает и защита обходится), а если уже не удаётся с первым, то соответственно беру уже второй.
Ещё иногда (очень редко) CSRF токены на сайте генерируются с помощью Java скрипта, что в принципе тоже можно перехватить просто отправив GET запрос на этот .js файл на сайте, в ответе так же будет наш заветный токен.
1. На сайте cpooutlets.com авторизация происходит со страницы https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show.
2. Авторизация происходит путём отправки данных loginEmail, loginPassword, csrf_token в формате application/x-www-form-urlencoded в виде POST запроса на ссылку https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show
Данные в запросе отправляются в таком виде:
3. Сайт защищен с помощью динамического CSRF токена, что усложняет процесс написания программы, которая будет автоматически перебирать валидные комбинации EMAIL:PASS.
4. На сайте cpooutlets.com CSRF токен получается обычным GET запросом на ссылку страницы авторизации и просто парсится из HTML кода, который приходит в ответе на наш GET запрос. Перед отправкой POST запроса на авторизацию нам нужно просто спарсить его из содержимого ответа на GET запрос и подставить в POST запрос.
5. В случае НЕУДАЧНОГО входа в аккаунт мы получим ответ от сайта в виде JSON с содержимым "error":
6. В случае УДАЧНОГО входа в аккаунта мы получим ответ от сайта в виде JSON с содержимым "success": true и "redirectUrl": "/Account?Registration=false"
Имея все эти знания о нашей цели мы наконец-то можем приступить к созданию нашего конфига для OpenBullet, который будет выступать в роли Брут/Чекера для этого сайта. Но пока на этом всё, чтобы не перегружать вас и себя всё остальное будет во второй статье. Вторая часть выйдет через день/два после публикации первой статьи.
Эксклюзивно для форума: xss.pro
Часть: [1/3]
Ссылка на вторую статью: xss.pro/threads/125492/
Ссылка на третью статью: xss.pro/threads/125906/
Предисловие
Доброго времени суток, жители форума! В своё время я потратил довольно таки кругленькую сумму на то, чтобы платить кодерам за разработку брутов/чекеров/парсеров, но потом мне это надоело и я решил научиться делать это сам, о чём в последствии ни капли не жалею, ведь это помогло мне оставить в своём кармане не одну тысячу вечно зелёных.
Серия уроков будет разбита на две статьи.
В моих статьях мы поймём как и где ловить HTTP запросы, рассмотрим как с помощью Open Bullet можно написать Brute/Checker с помощью HTTP запросов на сайтах, где есть защита в виде CSRF токена.
Научимся находить CSRF токен, парсить его и использовать для авторизации на сайте.
Хочу сразу сказать, что я не являюсь профессионалом в этом деле. Я не программист от слова совсем, без помощи ChatGPT мной небыло написано ни одной строчки кода, но это не мешает мне делать бруты под конторы, которые меня интересуют. Но ведь в этом и вся прелесть, что нам даже не нужно знать языки программирования, чтобы написать свой брут на какой-либо сервис, я полностью за NO CODE! Ведь зачем нужно кодить, если можно не кодить, верно?
В этих статьях я просто хочу передать свой опыт, если вы делаете как-то по другому, или же у вас есть советы, то я буду рад увидеть и изучить ваши сообщения в данной теме!
Первая статья больше для новичков, но возможно и некоторые опытные пользователи для себя что-то подчеркнут. Помните, что для каждого сайта чаще всего нужен свой подход, но эта информация поможет вам понять самую БАЗУ и что в принципе нужно делать при создании брута/чекера.
Что нам понадобится в этой серии уроков?
- Open Bullet - это бесплатный инструмент для автоматизации задач и тестирования веб-приложений с возможностью создания скриптов и конфигураций. Скачать можно здесь [кликабельно].
- Браузер Mozilla Firefox - для удобного отслеживания запросов от сайта. Это лично на вкус и цвет, но мне больше всего нравится отслеживать запросы от сайтов именно через этот браузер, потому что в Google Chrome мне не нравится интерфейс. Скачать можно здесь [кликабельно].
- Сайт cpooutlets.com - именно для этого сайта мы будем делать наш скрипт. Здесь как раз есть CSRF токен в запросе авторизации.
- Валидный аккаунт сайта, на который мы будем делать брут - аккаунт нам нужен, чтобы выполнять и отлавливать запросы. Ведь мы должны понять какой ответ приходит от сайта, если аккаунт валидный, а так же чтобы понять откуда нам парсить нужные значения для нашего чекера, если аккаунт валидный (например кол-во заказов, привязанные карты и т.д). Можете просто зарегистрироваться сами, хоть на временную почту. Я почти везде использую для регистрации cryptogmail.com, если сервис не очень популярный, то он с вероятностью 90% даст пройти регистрацию на эту временную почту.
- Знания что такое POST и GET запросы - просто запомните, что POST используется для передачи данных на сервер (например, когда мы отправляем комментарий или входим на сайт), а GET — для получения данных с сервера (например, загрузка страницы или поисковый запрос).
>Этап 1. Ищем страницу авторизации.<
Как я уже написал раньше - нашей целью будет сайт cpooutlets.com.
Первым делом я всегда нахожу отдельную/альтернативную страницу входа на сайт, так будет проще работать, потому что в запросах будет меньше мусора (просто будет меньше подгружать картинок, скриптов и т.д.).
В этом мне помогают Google Dorks (они же дорки).
В нашем случае я буду использовать дорк:
Код:
site:"cpooutlets.com" (login OR signin OR "sign-in" OR "sign in")Мы успешно нашли страницу авторизации.
В поле site:"" можете подставлять любой свой целевой сайт и он скорее всего найдёт отдельную страницу входа (если она вообще существует, у некоторых сайтов просто нет такой ОТДЕЛЬНОЙ страницы)
С помощью этого способо я ни один раз находил альтернативные способы авторизации, потому что глупый админ на сайте с посещалкой от 1КК просто забывал выключить и убрать из выдачи, например, старую страницу авторизации где нет защиты, НО ОНА ПРИ ЭТОМ ВСЁ ЕЩЁ РАБОТАЛА! Поэтому всегда старайтесь эксперементировать с дорками, иногда это приносит свои плоды, мой дорк выше НЕ ЯВЛЯЕТСЯ УНИВЕРСАЛЬНЫМ.
>Этап 2. Находим запрос авторизации.<
Теперь, когда мы уже находимся на странице авторизации мы должны нажать F12 и перейти во вкладку Network. Либо нажать "CTRL + SHIFT + E".
Как мы видим таким образом я открыл сетевой монитор, чтобы отслеживать и анализировать HTTP запросы, которые наш браузер отправляет сайту и ответы, которые наш браузер получает от сайта.
Теперь давайте попробуем ввести в поля "Email" и "Password" какие-нибудь случайные данные и нажать на кнопку входа (SIGN IN), при этом сетевой монитор должен быть открыт!
После нажатия на кнопку входа в аккаунт, как и ожидалось, мы не вошли в аккаунт, но на данном этапе нам это и не нужно. Зато мы получили в сетевом мониторе информацию, которая гласит следующее:
Когда мы нажимаем на кнопку входа, то сайт отправляет POST запрос на адрес "www.cpooutlets.com/Account-Login?rurl=1"
>Этап 2.1. Читаем POST запрос авторизации и собираем необходимые данные.<
И так, теперь давайте посмотрим содержимое этого запроса (для этого просто кликните по нему ЛКМ в сетевом мониторе).
Чаще всего нас будут интересовать только вкладки "Headers", "Request" и "Response". Давайте разберем каждую из них и выпишем всю необходимую информацию для формирования запроса.
ВКЛАДКА "HEADERS"
В данном разделе мы можем найти следующую информацию:
1. Ссылку, на которую отправляется POST запрос. (А именно )
2. Версию HTTP, которая используется при отправке POST запроса, а именно HTTP/2
3. Необходимые заголовки, которые от нас требует сайт при отправке запроса. (Вкладка Request Headers). Рекомендую ставить галочку в поле "Raw" напротив "Request Headers" как на скриншоте, так удобнее скопировать необходимые заголовки.
Request Headers — это как записка, которую ты отправляешь вместе с сообщением. В записке ты рассказываешь сайту важные вещи, например, какое у тебя устройство (ПК, или телефон), каким "языком" ты говоришь и как сайт должен прочитать твои данные. Это помогает сайту правильно понять и ответить на твой запрос.
4. Во вкладке "Requst Headers" есть такая строка как "Content-Type". В нашем случае там написано "application/x-www-form-urlencoded".
Типы данных в Content-Type для POST запроса — это как разные упаковки для того, что мы отправляем сайту.
Самые распространённые типы:
application/x-www-form-urlencoded — форма, где данные идут как текст.
multipart/form-data — для отправки файлов (например, картинок).
application/json — данные отправляются как текст в виде списка или таблицы.
Эти "упаковки" помогают сайту понять, в каком формате ему нужно принять данные.
Все эти данные будут нужны для корректного построения POST запроса при создании конфига в OpenBullet. Это мы будем делать во втором уроке, сейчас мы пока просто проводим разведку нашей цели.
ВКЛАДКА "REQUEST"
В данном разделе конкретно в этом случае мы можем найти содержимое нашего POST запроса, которое включает в себя следующее:
1. Наш электронную почту в поле "loginEmail"
2. Наш пароль в поле "loginPassword"
3. Защита в виде CSRF токена, который динамически генерируется сайтом перед тем, как человек нажмёт на кнопку входа. Его мы видим в поле "csrf_token"
CSRF токен — это специальный секретный код, который сайт добавляет в POST запросы. Он помогает убедиться, что запрос действительно сделан пользователем, а не кем-то посторонним.
Как это работает: когда ты заполняешь форму на сайте, сайт добавляет этот код в запрос. Когда сервер получает запрос, он проверяет этот код. Если его нет или он неправильный, сервер понимает, что это может быть атака, и отклоняет запрос. Это защищает от того, чтобы злоумышленники не отправили запрос от твоего имени без твоего согласия.
Таким образом, если бы на сайте небыло CSRF токена, нам бы было достаточно иметь только Email и Password, чтобы отправить POST запрос и получить корректный ответ от сервера. Но так как он есть, то без него мы просто получим в ответ ошибку от сайта. Во второй статье мы проверим это на практике.
В этой (первой) статье чуть позже мы уже научимся находить CSRF токен для того, чтобы потом использовать его и успешно отправлять POST запросы. Но в этом уроке мы найдём его вручную, чтобы понять принцип, а потом уже во втором уроке автоматизируем этот процесс.
Так же хочу добавить, что мы уже поняли из Content-Type во вкладке HEADERS (см. выше), что при отправке POST запроса у нас использутся формат данных application/x-www-form-urlencoded.
Давайте нажмём галочку "Raw" во вкладке "Request" и посмотрим, как содержимое нашего запроса выглядит на самом деле:
А именно:
Код:
loginEmail=leonidfilatov%40gmail.com&loginPassword=51234123213&csrf_token=XDULt9hixGIvW3BPwfauXuGL6Hc77JqduYCsT_L7927a-6OKNpVaeZz3vMsLctix6d4XTRJzfBEnx3M9zac7YU1Q7-tuSA_tdBKkDV0D2pAXXaysjl82IE5CFKIS0uTWOYCEipRKq-S3ZwqNhE81iLLFYn7oaQxIKR1xQxtpYDtO26EP2nE%3DКак мы видим наши данные самую малость закодированы, например почта выглядит как "leonidfilatov%40gmail.com", а должна быть "leonidfilatov@gmail.com".
Давайте раскодируем наши данные, так будет удобнее строить запрос в будущем:
1. Просто идём на сайт urldecoder.org
2. Вставляем содержимое нашего запроса в поле ввода, жмём "Decode" и получаем результат.
Мы получили:
Код:
loginEmail=leonidfilatov@gmail.com&loginPassword=51234123213&csrf_token=XDULt9hixGIvW3BPwfauXuGL6Hc77JqduYCsT_L7927a-6OKNpVaeZz3vMsLctix6d4XTRJzfBEnx3M9zac7YU1Q7-tuSA_tdBKkDV0D2pAXXaysjl82IE5CFKIS0uTWOYCEipRKq-S3ZwqNhE81iLLFYn7oaQxIKR1xQxtpYDtO26EP2nE=ВКЛАДКА "RESPONSE"
В этой вкладке мы можем увидеть какие данные сервер отправил нам в своём ОТВЕТЕ на наш POST запрос и в каком формате приходит этот ответ. Так же нажимаем "Raw", чтобы увидеть настоящий вид ответа от сайта.
Как мы можем увидеть - сайт отвечает нам в формате JSON. Так же в "error": мы можем увидеть сообщение, которое выходит при неудачной попытке входа в аккаунт, если логин и пароль НЕ ЯВЛЯЮТСЯ валидной комбинацией.
Во второй статье мы будем использовать этот ответ от сервера, чтобы определить аккаунт как "BAD".
>Этап 2.2. Попробуем войти с помощью ВАЛИДНОГО аккаунта.<
В ходе написания статьи в голову пришло ещё то, что нужно всё таки показать какой ответ от сервера будет, если аккаунт оказался валидным и мы успешно вошли в аккаунт.
Про вкладку "Headers" и "Request" объяснять смысла нет, потому что там по сути осталось всё тоже самое, что и в пункте 2.1.
А вот вкладка "Response" будет отличаться, ведь мы УСПЕШНО ВОШЛИ в аккаунт.
Я думаю вы заметили, что ответ изменился. У нас больше нет "error", зато появились "success": true и "redirectUrl": "/Account?Registration=false"
Таким образом сайт сообщил нам, что мы УСПЕШНО вошли в аккаунт.
Во второй статье мы будем использовать этот ответ от сервера, чтобы определить аккаунт как "GOOD" и продолжить с него парсинг всей информации (кредитные карты, имя, адрес, заказы).
>Этап 3. Как найти CSRF токен, чтобы использовать его в POST запросе и обойти защиту.<
В начале статьи я уже сказал, что нам понадобятся знания не только о POST, а ещё и о GET запросах.
И так же я уже сказал, что токен генерируется ДИНАМИЧЕСКИ при каждом заходе на страницу.
По сути исходя из этой информации мы уже можем сделать вывод, что для получения CSRF токена нужно просто сделать GET запрос на страницу, на которой находится форма авторизации.
В нашем случае это: "https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show"
1. Открываем пустую вкладку браузера, открываем сетевой монитор (см. этап 2)
2. Вставляем в адресную строку нашу ссылку на страницу авторизации
3. Переходим по ссылке и видим, что в нашем сетевом мониторе появися GET запрос на страницу, которую мы открыли.
4. Смотрим содержимое вкладки "Response", чтобы посмотреть содержимое, которое мы получили от сайта в результате нашего GET запроса.
Отлично, мы получили ответ в виде HTML страницы, теперь нам нужно посмотреть исходный код этой HTML страницы.
5. Как обычно жмём "Raw", чтобы посмотреть настоящий вид данных (в нашем случае код страницы HTML).
Потом жмём CTRL + A, чтобы выбрать весь код и копируем его для удобства в .txt файл, я буду использовать удобный редактор Notepad++.
После того как скопировали код в Notepad++, жмем CTRL+F и вводим в поле "Найти" значение "CSRF", после чего жмем на кнопку поиска.
В нашем случае токен нашёлся сразу, без каких либо заморочек. В данном случае он находится в значении value="hJKUCe........"
На некоторых сайтах он не будет находится настолько легко. Он может быть подписан просто как "token", либо же ещё как-нибудь. Но как показывает практика почти на всех сайтах он спокойно ищется по "CSRF".
Иногда может быть, что в коде страницы будет находится сразу ДВА CSRF токена, обычно я просто пробую подставить в запрос сначала первый, то есть самый верхний CSRF токен (что в 90% случаев срабатывает и защита обходится), а если уже не удаётся с первым, то соответственно беру уже второй.
Ещё иногда (очень редко) CSRF токены на сайте генерируются с помощью Java скрипта, что в принципе тоже можно перехватить просто отправив GET запрос на этот .js файл на сайте, в ответе так же будет наш заветный токен.
>Этап 4. Вывод. Собираем информацию о сайте в кучу.<
Фух, вот мы и собрали информацию о нашей цели. Теперь давайте обобщим всё это и сделаем вывод.
1. На сайте cpooutlets.com авторизация происходит со страницы https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show.
2. Авторизация происходит путём отправки данных loginEmail, loginPassword, csrf_token в формате application/x-www-form-urlencoded в виде POST запроса на ссылку https://www.cpooutlets.com/on/demandware.store/Sites-cpooutlets-Site/default/Login-Show
Данные в запросе отправляются в таком виде:
Код:
loginEmail=leonidfilatov@gmail.com&loginPassword=51234123213&csrf_token=XDULt9hixGIvW3BPwfauXuGL6Hc77JqduYCsT_L7927a-6OKNpVaeZz3vMsLctix6d4XTRJzfBEnx3M9zac7YU1Q7-tuSA_tdBKkDV0D2pAXXaysjl82IE5CFKIS0uTWOYCEipRKq-S3ZwqNhE81iLLFYn7oaQxIKR1xQxtpYDtO26EP2nE=4. На сайте cpooutlets.com CSRF токен получается обычным GET запросом на ссылку страницы авторизации и просто парсится из HTML кода, который приходит в ответе на наш GET запрос. Перед отправкой POST запроса на авторизацию нам нужно просто спарсить его из содержимого ответа на GET запрос и подставить в POST запрос.
5. В случае НЕУДАЧНОГО входа в аккаунт мы получим ответ от сайта в виде JSON с содержимым "error":
6. В случае УДАЧНОГО входа в аккаунта мы получим ответ от сайта в виде JSON с содержимым "success": true и "redirectUrl": "/Account?Registration=false"
Имея все эти знания о нашей цели мы наконец-то можем приступить к созданию нашего конфига для OpenBullet, который будет выступать в роли Брут/Чекера для этого сайта. Но пока на этом всё, чтобы не перегружать вас и себя всё остальное будет во второй статье. Вторая часть выйдет через день/два после публикации первой статьи.
Вложения
Последнее редактирование:
