Translated article

Статью перевела, замечания и пожелания по переводу приветствуются.
Также не знаю, нужно ли переводить текст в коде в файлах-примерах (которые отдельно от статьи идут).

Author: tay-na

3-frames-and-windows/06-clickjacking/Translated article.md

@@ -0,0 +1,221 @@
+Атака Clickjacking
+
+Атака типа "clickjacking" (англ. "захват клика") позволяет вредоносной странице кликнуть по "сайту жертве" от имени посетителя.
+
+Многие сайты были взломаны подобным способом, включая Twitter, Facebook, Paypal и другие. Все они, конечно же, были восстановлены.
+
+Идея
+
+Идея данной атаки очень проста.
+
+Вот как clickjacking атака была проведена для Facebook:
+
+Посетителя заманивают на вредоносную страницу (не важно как).
+На странице есть ссылка, которая выглядит безобидно (например "Разбогатей прямо сейчас" или "Нажми здесь, это очень смешно").
+Поверх этой ссылки вредоносная страница размещает прозрачный <iframe> с src с сайта facebook.com таким образом, что кнопка "like" находится прямо над этой ссылкой. Обычно это делается с помощью z-index в CSS.
+При попытке клика на эту ссылку, посетитель на самом деле нажимает на кнопку.
+
+Демонстрация
+
+Вот как выглядит вредоносная страница. Для наглядности <iframe> полупрозрачный (на реальных вредоносных страницах он полностью прозрачен):
+
+<style>
+iframe { /* iframe с сайта жертвы */
+width: 400px;
+height: 100px;
+position: absolute;
+top:0; left:-20px;
+*!*
+opacity: 0.5; /* в реальности opacity:0 */
+*/!*
+z-index: 1;
+}
+</style>
+
+<div>Нажми, чтобы разбогатеть:</div>
+
+<!-- The url с сайта жертвы -->
+*!*
+<iframe src="/clickjacking/facebook.html"></iframe>
+
+<button>Нажмите сюда!</button>
+*/!*
+
+<div>...И ты крутой (вообще-то я крутой хакер)!</div>
+
+Полная демонстрация атаки:
+
+[codetabs src="clickjacking-visible" height=160]
+
+Здесь у нас есть полупрозрачный <iframe src="facebook.html">, и в примере мы видим его висящим поверх кнопки. Клик на кнопку фактически кликает на iframe, но это не видно пользователю, потому что iframe прозрачный.
+
+В результате если пользователь авторизован на сайте Facebook ("Запомнить меня" обычно всегда активировано), то он добавляет "like". В Twitter это будет кнопка "Follow".
+
+Вот тот же пример, но более приближенный к реальности с opacity:0 для <iframe>:
+
+[codetabs src="clickjacking" height=160]
+
+Всё, что нам необходимо для атаки — это расположить <iframe> на вредоносной странице так, чтобы кнопка находилась прямо над ссылкой. Обычно это можно сделать с помощью CSS-позиционирования.
+
+Эта атака срабатывает только на действия мыши.
+
+Технически, если у нас есть текстовое поле для взлома, мы можем расположить iframe таким образом, чтобы текстовые поля перекрывали друг друга. Тогда посетитель при попытке сфокусироваться на текстовом поле, которое он видит на странице, фактически будет фокусироваться на текстовом поле внутри iframe.
+
+Но есть одна проблема. Всё, что посетитель печатает, будет скрыто, потому что iframe не виден. Обычно люди перестают печатать, когда не видят на экране новых символов.
+
+Примеры слабой защиты
+
+Самым старым вариантом защиты является код JavaScript, запрещающий открытие страницы во фрейме (так называемый "framebusting").
+
+Выглядит он вот так:
+
+if (top != window) {
+top.location = window.location;
+}
+
+В этом случае если окно обнаруживает, что оно открыто во фрейме, оно автоматически располагает себя сверху.
+
+Этот метод не является надёжной защитой поскольку появилось множество способов его обойти. Рассмотрим некоторые из них.
+
+Блокировка top-навигации.
+Мы можем заблокировать переход вызванный сменой top.location в beforeunload событии.
+
+Верхняя страница (принадлежащая хакеру) устанавливает обработчик на это событие, и когда iframe пытается изменить top.location, посетитель видит сообщение с вопросом действительно ли он хочет покинуть эту страницу.
+
+Вот пример:
+
+window.onbeforeunload = function() {
+window.onbeforeunload = null;
+return "Ты хочешь покинуть эту страницу так и не узнав все её секреты (ха-ха-ха)?";
+};
+
+В большинстве случаев посетитель ответит отрицательно, поскольку он не знает об iframe - всё что он видит, это верхнюю страницу, которую нет причин покидать. Поэтому top.location не изменится.
+
+В действии:
+
+[codetabs src="top-location"]
+
+Атрибут Sandbox
+
+Одной из возможностей, ограниченных в sandbox атрибутах, является навигация. Соответственно iframe внутри sandbox не изменит top.loacation.
+
+Поэтому мы можем добавить iframe с sandbox="allow-scripts allow-forms". Это снимет некоторые ограничения, разрешая при этом использование скриптов и форм. Но мы опускаем allow-top-navigation, чтобы изменение top.location было запрещено.
+
+Вот код данного примера:
+
+<iframe *!*sandbox="allow-scripts allow-forms"*/!* src="facebook.html"></iframe>
+
+Есть и другие способы обойти эту простую защиту.
+
+Заголовок X-Frame-Options
+
+Заголовок X-Frame-Options со стороны сервера может разрешать или запрещать отображение страницы внутри фрейма.
+
+Этот заголовок должен быть отправлен сервером: браузер проигнорирует его, если найдет в теге <meta>. Поэтому при <meta http-equiv="X-Frame-Options"...> ничего не произойдёт.
+
+Заголовок может иметь 3 значения:
+
+DENY : Никогда не показывать страницу внутри фрейма.
+
+SAMEORIGIN : Разрешить открытие страницы внутри фрейма только в том случае, если родительский документ имеет такое же происхождение.
+
+ALLOW-FROM domain : Разрешить открытие страницы внутри фрейма только в том случае, если родительский документ находится на указанном в заголовке домене.
+
+Например, Twitter использует X-Frame-Options: SAMEORIGIN.
+
+Вот результат:
+
+'''html
+<iframe src="https://twitter.com"></iframe>
+'''
+
+<!-- ebook: prerender/ chrome headless dies and timeouts on this iframe -->
+<iframe src="https://twitter.com"></iframe>
+
+В зависимости от того, какой браузер вы используете, iframe выше либо будет пустым, либо оповестит вас о том, что его невозможно отобразить.
+
+Отображение с ограниченными возможностями.
+
+У заголовка X-Frame-Options есть побочный эффект. Другие сайты не смогут отобразить нашу страницу во фрейме даже если у них будут на то веские причины.
+
+Так что есть другие решения.
+
+Например, мы можем "накрыть" страницу блоком <div> с заданными height: 100%; и width: 100%;, чтобы он перехватывал все клики. Этот <div> должен исчезнуть если window == top или если мы поймём, что защита нам не нужна.
+
+Что-то вроде этого:
+
+<style>
+#protector {
+height: 100%;
+width: 100%;
+position: absolute;
+left: 0;
+top: 0;
+z-index: 99999999;
+}
+</style>
+
+<div id="protector">
+<a href="/" target="_blank">Перейти к сайту</a>
+</div>
+
+<script>
+// Здесь будет отображаться ошибка, если верхнее окно имеет другое происхождение
+// а здесь будет код, если всё в порядке
+if (top.document.domain == document.domain) {
+protector.remove();
+}
+</script>
+
+Демонстрация:
+
+[codetabs src="protector"]
+
+Samesite cookie атрибут
+
+Атрибут Samesite cookie также может не допустить clickjacking атаку. Целью этого атрибута является предотвращение отправки файлов cookie на веб-сайт, если пользователь не намерен посещать его. Этот атрибут был придуман для защиты от другой атаки — подделки межсайтовых запросов, но также помогает с clickjacking поскольку перехваченный клик обычно приводит к непреднамеренному запросу на другую страницу. Когда файл cookie имеет samesite атрибут, принимает ли он при этом значение strict или lax, он не отправляется на сайт, который загружен во фрейме.
+
+Атрибут samesite может быть задан либо через заголовок ответа HTTP, либо с помощью JavaScript. Через HTTP это выглядит так:
+
+Set-Cookie: demoCookie=demoValue; samesite=lax
+
+или
+
+Set-Cookie: demoCookie=demoValue; samesite=strict
+
+С помощью JavaScript:
+
+document.cookie = "demoCookie=demoValue; SameSite=Lax";
+document.cookie = "demoCookie=demoValue; SameSite=Strict";
+
+Если задано значение lax, следующие типы запросов блокируются:
+
+Form POST submit (<form method="POST" action="...">)
+iframe (<iframe src="..."></iframe>)
+AJAX ($.get("..."))
+Image (<img src="...">)
+Script (<script src="..."></script>)
+Stylesheet (<link rel="stylesheet" type="text/css" href="...">)
+
+Если задано значение strict, эти типы запросов также блокируются, в дополнение к тем, что блокируются с помощью lax:
+
+Clicking a link (<a href="..."></a>)
+Prerender (<link rel="prerender" href=".."/>)
+Form GET submit (<form method="GET" action="...">)
+
+В данном случае нас беспокоит запрос через iframe. Попытка перехвата провалится, поскольку предполагается что пользователь не авторизован, например на странице Facebook, и не может лайкнуть ничего через iframe.
+
+Атрибут samesite не сыграет никакой роли, если cookie-файлы не используются. Это может позволить веб-сайтам легко отображать публичные, неаутентифицированные страницы в iframe на неаффилированных сайтах. Однако, это также может позволить проведение clickjacking атаки в некоторых случаях. Например, сайт для анонимных опросов, который предотвращает повторное голосование пользователя путем проверки IP адреса, останется уязвимым к атаке, потому что не аутентифицирует пользователей с помощью cookies.
+
+Итого
+
+Атака сlickjacking - это способ "обмануть" пользователей, чтобы они кликнули на вредоносный сайт, не подозревая, что происходит. Это опасно, если на странице есть важные действия, активируемые щелчком мыши.
+
+Хакер может разместить ссылку на свою вредоносную страницу в сообщении или найти другие способы как заманить пользователей. Вариантов множество.
+
+С одной стороны — эта атака "неглубокая", ведь хакер перехватывает только один клик. Но с другой стороны, если хакер знает, что после этого клика появятся другие элементы управления, то он может хитростью заставить пользователя кликнуть на них.
+
+Данная атака довольно опасна, ведь при разработке интерфейсов мы не предполагаем, что хакер может кликнуть от имени пользователя. Поэтому уязвимости могут быть обнаружены в совершенно неожиданных местах.
+
+В настоящий момент для защиты от этой атаки рекомендуется использовать X-Frame-Options: SAMEORIGIN на страницах и целых сайтах, которые не предназначены для просмотра во фрейме.
+Если же мы хотим отображать страницу во фрейме и при этом оставаться в безопасности, то стоит использовать перекрывающий блок <div>.