Если вы знакомы с концепцией IDOR (Insecure Direct Object Reference), то знаете, что эта уязвимость может быть где угодно: в URL, теле запроса, запросах GET или POST, а также в cookie.
Я участвовал в одной приватной программе. начала, я начал изучать логику работы приложения. Обычно это дает возможность (но не всегда), обнаружить много уязвимостей. Именно это и произошло у меня … В итоге я занял место в рейтинге программы, сразу за несколькими известными хакерами.
Возвращаемся к сути
При тестировании и анализе работы веб-приложения я обычно ищу любые токены или идентификаторы, которые можно использовать для получения информации или выполнения критических действий, приводящих к IDOR.
Я пытался найти проблему с CSRF. Там я заметил, что в cookie присутствует параметр shoppingID, который оказался сессионной cookie.
При более внимательном рассмотрении значения cookie я обнаружил нечто, что сразу привлекло мое внимание:
Если заметили, поздравляю! У вас острый глаз на потенциальные IDOR.
В конце cookie указано SESSIONID и семь цифр: SESSIONID3552522. Я быстро создал новую учетную запись и проверил значение сессионной cookie, которое оказалось очень похожим, но с небольшими отличиями:
Я проанализировал значение cookie. И я понял, что эти случайные символы не проверяются сервером, поэтому изменение только числового идентификатора (7 цифр после SESSIONID) давало мне полный доступ к любому аккаунту.
Вот как выглядела структура cookie, разделенная на части A, B и C:
После создания нескольких аккаунтов я выяснил следующее:
[A] = Эта часть повторялась в моих тестовых аккаунтах, паттерн, который проверялся на сервере (существуют и другие различные паттерны).
= Это номер, который присваивается аккаунту инкрементально при его создании, это уязвимость.
[C] = Это комбинация случайных цифр и букв, которая не проверяется на сервере.
Поскольку был только числовым, [C] не проверялся, а [A] был паттерном, повторяющимся на других аккаунтах, было возможно просто провести брутфорс ID для получения полного доступа к другим аккаунтам.
Этот токен доступа был постоянным и не изменялся со временем. Это давало полный доступ к другим аккаунтам, включая кредитные карты, если они хранились в этих аккаунтах.
Команде H1 потребовалось некоторое время, чтобы понять, что возможен IDOR сессионной cookie. В конце концов проблема была решена, и мне была выплачена награда в размере 2000 долларов за критическую уязвимость.
Это всё, надеюсь, вам понравилось
Я участвовал в одной приватной программе. начала, я начал изучать логику работы приложения. Обычно это дает возможность (но не всегда), обнаружить много уязвимостей. Именно это и произошло у меня … В итоге я занял место в рейтинге программы, сразу за несколькими известными хакерами.
Возвращаемся к сути
При тестировании и анализе работы веб-приложения я обычно ищу любые токены или идентификаторы, которые можно использовать для получения информации или выполнения критических действий, приводящих к IDOR.
Я пытался найти проблему с CSRF. Там я заметил, что в cookie присутствует параметр shoppingID, который оказался сессионной cookie.
При более внимательном рассмотрении значения cookie я обнаружил нечто, что сразу привлекло мое внимание:
Замечаете что-то? Если нет, не продолжайте чтение, посмотрите на это снова.
Если заметили, поздравляю! У вас острый глаз на потенциальные IDOR.
В конце cookie указано SESSIONID и семь цифр: SESSIONID3552522. Я быстро создал новую учетную запись и проверил значение сессионной cookie, которое оказалось очень похожим, но с небольшими отличиями:
Большая часть значения cookie была одинаковой в обеих сессиях, что обычно является потенциальной уязвимостью. Первая часть значения была полностью идентична, а различия заключались в 5 случайных символах до и после SESSIONID{число}.
Я проанализировал значение cookie. И я понял, что эти случайные символы не проверяются сервером, поэтому изменение только числового идентификатора (7 цифр после SESSIONID) давало мне полный доступ к любому аккаунту.
Вот как выглядела структура cookie, разделенная на части A, B и C:
После создания нескольких аккаунтов я выяснил следующее:
[A] = Эта часть повторялась в моих тестовых аккаунтах, паттерн, который проверялся на сервере (существуют и другие различные паттерны).
= Это номер, который присваивается аккаунту инкрементально при его создании, это уязвимость.
[C] = Это комбинация случайных цифр и букв, которая не проверяется на сервере.
Поскольку был только числовым, [C] не проверялся, а [A] был паттерном, повторяющимся на других аккаунтах, было возможно просто провести брутфорс ID для получения полного доступа к другим аккаунтам.
Этот токен доступа был постоянным и не изменялся со временем. Это давало полный доступ к другим аккаунтам, включая кредитные карты, если они хранились в этих аккаунтах.
Команде H1 потребовалось некоторое время, чтобы понять, что возможен IDOR сессионной cookie. В конце концов проблема была решена, и мне была выплачена награда в размере 2000 долларов за критическую уязвимость.
Это всё, надеюсь, вам понравилось
