Поехали IP: 62.173.140.174:16079
Не скажу, что прям легкий, но пришлось подумать в угоду своей новичковости
1) Переходим на сайт и исследуем
2) Регистрируемся с любыми данными
3) Логинимся под учетными данными
Получаем определенные исходные данные
4) Для теста создаем пару учетных данных например 111 и 222
У нас будут два разных токена
5) Обновляем страницу и в Burp в Proxy - HTTPhistory ищем запрос /profile
В нем передается Cookie: Token=9b871512327c09ce91dd649b3f96a63b7408ef267c8cc5710114e629730cb61f
GET /profile.php HTTP/1.1
Host: 62.173.140.174:16079
X-Requested-With: XMLHttpRequest
Accept-Language: en-US,en;q=0.9
Accept: /
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Referer:
Accept-Encoding: gzip, deflate, br
Cookie: Token=9b871512327c09ce91dd649b3f96a63b7408ef267c8cc5710114e629730cb61f
Connection: keep-alive
6) Для удобства запрос отправляем в репитер
Так как у нас два токена, пробуем подставить другой токен при запросе. Получаем ответ с авторизацией другого пользователя
7) Поразмышляв некоторое время, пришел к тому, что токен кодирован SHA256, идем декодить.
При декодировании получаем имя пользователя
8) Пробуем кодить admin в SHA256 (сразу не подумал и были зарегистрированы учетные данные admin самостоятельно - значит учетные данные не те которые ищем)
9) Обращаемся к блоку "Связаться с нами", видим учетную запись "administrator"
Кодируем данную учетную запись в SHA256
Получаем токен: 4194d1706ed1f408d5e02d672777019f4d5385c766a8c6ca8acba3167d36a7b9
10) Повторяем п.7 с подставлением полученного токена
Получаем флаг
Напишите в комментах какая это уязвимость. Что то отсылаюсь по токенам к JWT
Всем спасибо
Критика принимается
)))
и по традиции
«Не стыдно не знать, стыдно не учиться» — русская пословица.
Незнание само по себе не является позором, но отказ от обучения и игнорирование возможности исправить свои пробелы — это повод для стыда.
Не скажу, что прям легкий, но пришлось подумать в угоду своей новичковости
1) Переходим на сайт и исследуем
2) Регистрируемся с любыми данными
3) Логинимся под учетными данными
Получаем определенные исходные данные
4) Для теста создаем пару учетных данных например 111 и 222
У нас будут два разных токена
5) Обновляем страницу и в Burp в Proxy - HTTPhistory ищем запрос /profile
В нем передается Cookie: Token=9b871512327c09ce91dd649b3f96a63b7408ef267c8cc5710114e629730cb61f
GET /profile.php HTTP/1.1
Host: 62.173.140.174:16079
X-Requested-With: XMLHttpRequest
Accept-Language: en-US,en;q=0.9
Accept: /
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/133.0.0.0 Safari/537.36
Referer:
Ссылка скрыта от гостей
Accept-Encoding: gzip, deflate, br
Cookie: Token=9b871512327c09ce91dd649b3f96a63b7408ef267c8cc5710114e629730cb61f
Connection: keep-alive
6) Для удобства запрос отправляем в репитер
Так как у нас два токена, пробуем подставить другой токен при запросе. Получаем ответ с авторизацией другого пользователя
7) Поразмышляв некоторое время, пришел к тому, что токен кодирован SHA256, идем декодить.
При декодировании получаем имя пользователя
8) Пробуем кодить admin в SHA256 (сразу не подумал и были зарегистрированы учетные данные admin самостоятельно - значит учетные данные не те которые ищем)
9) Обращаемся к блоку "Связаться с нами", видим учетную запись "administrator"
Кодируем данную учетную запись в SHA256
Получаем токен: 4194d1706ed1f408d5e02d672777019f4d5385c766a8c6ca8acba3167d36a7b9
10) Повторяем п.7 с подставлением полученного токена
Получаем флаг
Напишите в комментах какая это уязвимость. Что то отсылаюсь по токенам к JWT
Всем спасибо
Критика принимается
)))и по традиции
«Не стыдно не знать, стыдно не учиться» — русская пословица.
Незнание само по себе не является позором, но отказ от обучения и игнорирование возможности исправить свои пробелы — это повод для стыда.
