Cookie:
Чтобы идентифицировать пользователя и поддерживать сеанс, они выдаются веб-сайтом, и они сохраняются в вашем файловом хранилище вашим браузером. Файлы cookie создаются, когда пользователь просматривает какой-либо веб-сайт, чтобы отслеживать ваши движения на этом веб-сайте, запоминая ваш логин. Файлы cookie позволяют серверу хранить и извлекать данные от клиента, данные могут быть такими, как уникальный идентификатор, назначенный клиенту веб-сайтом и т. Д.
Тип. Есть два типа файлов cookie:
· Сеансовые файлы cookie: они используются для проверки подлинности пользователя и назначаются только тогда, когда вы входите на сайт.
· Постоянный файл cookie: постоянный файл cookie остается во вложенной папке браузера в течение периода времени, установленного в файле cookie, и его можно использовать для аналитики и других целей.
Пример:
Потребность: HTTP не имеет состояния, поэтому каждый запрос уникален для сервера. Таким образом, чтобы клиент был аутентифицирован, веб-сайт выдает cookie, который может быть отправлен вместе с запросом, чтобы сообщить серверу, что Hey !! Я был аутентифицирован ранее, и вот файл cookie.
Установить cookie: всякий раз, когда браузер подключается к веб-сайту, который хочет отправить файл cookie клиенту, поэтому в этом случае веб-сайт включает заголовок «Set: Cookie» в ответ на этот запрос, который определяет файл cookie. который настраивает веб-сайт. После назначения файла cookie пользователю они автоматически добавляются к последующему запросу, отправляемому на этот конкретный веб-сайт.
Файлы cookie имеют следующие атрибуты:
· Имя: такая информация, как имя файла cookie, назначается сервером. Имя позволяет серверу различать файлы cookie сеанса и другие файлы cookie, такие как cookie сеанса, которые имеют имя session_id, а другие файлы cookie - файлы cookie аналитики.
· Срок действия: максимальный срок действия файла cookie. Он истечет по истечении времени, указанного в сроке действия.
· Домен: Домен указывает хост, на который будет отправлен файл cookie, если пользователь сделает запрос по URL-адресу, указанному в запросе домена, файл cookie будет автоматически включен в запрос.
я. Если мы не указали его, он отправит только значение основного домена, не включая в него поддомен.
II. Если указан домен, то всегда включаются поддомены.
Этот файл cookie будет действителен для всех доменов и субдоменов facebook, например * .facebook.com. Для любого домена, заканчивающегося на facebook.com, cookie будет действителен для всех поддоменов.
· Путь: путь, который должен существовать в запрошенном URL-адресе, иначе браузер не отправит заголовок файла cookie. После домена мы можем указать путь с помощью /.
· Безопасность: безопасный файл cookie добавляется в запрос только в том случае, если запрос поступает на порт 443.
В указанном выше файле cookie установлен флаг безопасности. Поэтому, если мы попытаемся отправить запрос через порт 80, cookie не будет включен в запрос.
Запрос:
Файл cookie не включается, так как запрос поступает на порт 443.
· Httponly: если для файла cookie установлен этот флаг, то клиентские сценарии JavaScript не смогут получить доступ к нему. что я беру в консоль и набираю "Итак, если я попытаюсь сделать" alert (document.cookie) ", чтобы проверить значение cookie.
Вы можете ясно видеть, что файл cookie не включен во всплывающее окно или в поле предупреждения.
· SameSite: если вы хотите ограничиться собственным контекстом или контекстом того же сайта.
я. Поскольку gupta.facebook.com является частью * .facebook.com. Итак, если gupta.facebook.com хочет включить некоторые изображения из основного домена facebook, то есть запрос с того же сайта.
II. Как gupta.facebook.com запрашивает какое-то изображение с test.facebook.com, то есть межсайтовый запрос.
Один и тот же файл cookie сайта имеет 3 атрибута:
· Lax: это значение по умолчанию, установленное в сегодняшнем браузере, поэтому файл cookie без атрибута samesite будет рассматриваться как установленный атрибут Lax. Cookie будут отправлены с навигацией верхнего уровня.
· Строгие: файлы cookie отправляются только с односторонним запросом, а не с сторонним инициатором.
· Нет: это означает, что cookie будет отправляться со всеми запросами, т.е. отправка межсайтовых запросов также разрешена.
Примечание. Ни "Строгие", ни "Слабые" решения не могут быть исчерпывающими. Cookie отправляются как часть запроса пользователя. Это означает дезинфекцию и проверку ввода.
Позвольте использовать уязвимость, соответствующую куки-файлу
Работа / использование:
При входе в систему у нас есть возможность выбрать, хотим ли мы войти на веб-сайт или нет, если выбрать «Оставаться в системе» в функциональности, которая присваивает атрибут в файле cookie.
Когда я пересылаю этот запрос, он фактически добавляет к нему значение cookie, которое можно использовать для дальнейшей аутентификации.
Заголовок cookie в приведенном выше запросе имеет 2 атрибута.
Сеанс: сеанс, который идентифицирует вошедшего в систему пользователя.
Оставаться в системе: он также имеет длинные буквенно-цифровые значения, которые будут входить в систему пользователя, если срок действия исходного файла cookie истечет. Давайте попробуем немного изучить файл cookie.
Перенаправьте этот запрос злоумышленнику и удалите атрибут сеанса из файла cookie, так как мы хотим, чтобы пользователь вошел в систему с помощью файла cookie с сохранением входа.
Кажется, что файл cookie закодирован в base64, давайте попробуем его расшифровать.
Итак, после декодирования мы видим, что файл cookie имеет два атрибута: один - мое имя пользователя, а другой - строка, которая выглядит как хэш.
После проверки я обнаружил, что это хеш md5, поэтому я взломал его с помощью любого взломщика md5 и обнаружил, что хеш md5 был паролем моей учетной записи.
Итак, давайте попробуем взломать cookie-файл stay_logged_in, чтобы выполнить обход аутентификации для другого пользователя.
Поэтому мы пересылаем вышеуказанный запрос злоумышленнику и начинаем грубую форсировку атрибута остаться в системе.
Запрос в Злоумышленнике
Для перебора пароля мне нужен один список паролей. Здесь я беру любой стандартный список паролей из Google и вставляю этот список во взломщика.
Как настроить обработку полезной нагрузки
Поскольку файл cookie закодирован в base64, и даже пароль был в md5, поэтому для грубой обработки cookie требуется обработка полезной нагрузки.
Воспользуемся обработкой полезной нагрузки
я. Преобразуйте список слов (один за другим) в хешированный md5
II. Добавьте префикс admin: в хешированный пароль
iii. Кодировка комбинации Base 64 (имя пользователя и хешированный пароль)
После всех настроек я начинаю атаку злоумышленника
Итак, как вы можете видеть в приведенном выше запросе, мы можем получить cookie-файл stay_logged_in для администратора. Мы можем использовать этот файл cookie, чтобы получить доступ к учетной записи администратора.
Исправление:
1. Функциональность stay_logged_in или «запомнить меня» должна быть реализована должным образом.
2. Имя пользователя и пароль пользователя не должны использоваться в файле cookie, поскольку это может привести к утечке пароля.
