Пересматривая старое и изучая новое: как много вы знаете о внешней безопасности

JavaScript
Пересматривая старое и изучая новое: как много вы знаете о внешней безопасности

передняя часть Seewo ENOW

Официальный сайт компании:CVTE (Гуанчжоу CVTE)

Команда: enow team центра программных платформ Seewo для будущего образования в рамках CVTE

Автор этой статьи:

предисловие

Привет, AV8D~ Тема, которой мы собираемся поделиться сегодня, — интерфейс.WebБезопасность.webВажность безопасности очевидна, и это тема, которую не могут обойти все интернет-компании.

В области веб-интерфейса, хотя браузеры уже сделали для нас много мер по изоляции и защите на системном уровне, открытость веб-кода иhtml、JSЯзыковые характеристики , чтобы у хакеров оставалось еще много возможностей, которыми можно было бы воспользоваться,Google、facebookИ так далее имеют свой собственный механизм вознаграждения за ошибки и стремятся найти и исправить ошибки до хакеров, чтобы минимизировать потери предприятий.

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

  • Общие проблемы безопасности интерфейса и соответствующие решения;
  • Немного хитростей и немного знаний о сетевых атаках;
  • Некоторые классические случаи атак через уязвимости;
  • и новые атаки, которые недавно вошли в нашу область;

XSS

1. Введение в XSS

XSSПолное имяCross-Site Scripting, межсайтовые скриптовые атаки. Это относится к использованию лазеек, оставшихся при разработке веб-страниц, для внедрения вредоносных кодов инструкций в веб-страницы с помощью хитрых методов, чтобы пользователи могли загружать и выполнять веб-программы, злонамеренно созданные злоумышленниками. С точки зрения непрофессионала, хакеры позволяют пользователям запускать свой собственный код атаки на посещаемых ими веб-страницах. После успешного запуска хакеры могут делать следующие вещи:

  • Получить текущего пользователя на этом сайтеcookies, чтобы получить конфиденциальную информацию пользователя;
  • Как текущий пользователь инициировать некоторые запросы операций, которые не предназначены пользователем, такие как удаление друзей с веб-сайта, публикация, отправка личных сообщений и т. д.;
  • выполнитьDDosатака;

В зависимости от источника атакиXSSЕго можно грубо разделить на постоянные атаки и непостоянные атаки (конечно, есть также типы отражения, хранения и типа Dom. Лично я предпочитаю первую категорию, потому что ее легче понять).

непостоянная атака

Характерной чертой непостоянного XSS является мгновенность. Его не нужно хранить на сервере. Умело сконструировав URL-адрес с вредоносным кодом, а затем направляя пользователей, чтобы щелкнуть, чтобы посетить, можно осуществить атаку.

Чтобы дать простой маленький каштан, предположим, что есть веб-сайт следующим образом.

Осторожно, вы обнаружите, что эта страница поместитurlнадqСодержимое параметра помещается на веб-страницу, и вы открываете консоль отладки, чтобы увидеть реализацию кода веб-страницы следующим образом:

<h1 id="query-key"></h1>
<span>查询结果如下</span>
// ...
<script>
  const reg = new RegExp("(^|&)q=([^&]*)(&|$)", "i");
  const res = window.location.search.substr(1).match(reg);
  if (res != null) {
      const query = decodeURIComponent(res[2]);
      document.getElementById('query-key').innerHTML = query;
  };
</script>

найти это неправильноqueryДелайте фильтрацию и используйте ее напрямуюinnerHTMLметод вставлен вDOM, вы чуть не расхохотались после прочтения: у вас вообще нет понятия безопасности! Итак, если вы хотите спроектироватьURLчтобы позволить пользователю щелкнуть, чтобы инициироватьXSSатака для получения доступа к пользователюcookiesданные, что бы вы сделали?

это не оченьso easy, вы можете написать наотмашьXSSВыходит ссылка:

http://abcd.com?q=<script>alert(document.cookie)</script>

Эта страница будетqТег script в параметре вставляется в DOM для выполнения, и появляется окно подсказки.

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

http://abcd.com?q=<img src="" onerror="alert(document.cookie)" />

Поскольку картинка вставляется, браузеры обычно не фильтруют и не перехватывают, и тогда мы ставимsrcпусто, чтобы вызватьonerrorсобытие, косвенно выполняющее наш вредоносный скрипт. Готово!

постоянная атака

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

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

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

Пользователь А написал в комментарии вредоносный код и отправил его в фоновый режим:

Когда пользователь B посещает эту страницу комментариев, страница загружает комментарий A, который запускает вредоносный код (в настоящее время пользователь B на самом деле ничего не делает, он просто очень послушно открывает этот очень формальный веб-сайт, а затем его вербуют ):

Таким образом, мы можем обобщить характеристики постоянного XXS:

  • Он постоянный, поскольку хранится в базе данных;
  • Поскольку нет необходимости побуждать пользователей переходить по вредоносным ссылкам, чтобы вызвать атаки, цель атак легче достичь, поэтому постоянный XSS более вреден;

2. Защита

После введения концепции мы можем знать, что для защиты от XSS-атак мы, вероятно, можем начать с двух аспектов:

  • Найдите способы предотвратить внедрение и выполнение вредоносного кода;
  • Используйте более безопасный метод для проверки и защиты учетных данных пользователя, чтобы уменьшить вред, причиняемый XSS-атаками;

1. Используйте экранирование HTML. Всегда будьте осторожны с вставленным извне контентом. Весь внешне вставленный код должен быть экранирован один раз, заменивscript,& < > " ' /Выполняйте фильтрацию и избегайте замены опасных символов и старайтесь избегать использованияinnerHTML,document.write,outerHTML,evalи другие методы, используя более безопасныйtextContent,setAttributeи другие способы замены;

2. Включите защиту CSP. Политика безопасности контента (CSP) предназначена для защиты от XSS-атак путем установки заголовка HTTP.Content-Security-Policy, вы можете настроить политику, если для CSP установлен следующий режим:

Content-Security-Policy: script-src 'self'

Тогда сайт будет:

  • Выполнение встроенного скрипта не допускается;
  • Загрузка чужого кода запрещена;
  • Представления вне домена запрещены;

Это позволит эффективно предотвращать XSS-атаки.Конечно, это также очень строго, что может накладывать определенные ограничения на развитие собственного бизнеса.Для получения дополнительной информации о CSP, пожалуйста, обратитесь кMDN.

3. Установите Только HTTP. Конечно, это уже метод снижения вреда XSS, для всех куки, содержащих конфиденциальную информацию, они должны быть установлены на стороне сервера.httpOnly, установленоhttpOnlyПоля cookie нельзя получить через JS, что снижает риск утечки конфиденциальных учетных данных пользователя во время XSS-атак.

CSRF

1. Введение в CSRF

Это еще один знакомый момент, который часто задают на собеседованиях.

CSRF (Подделка межсайтового запроса) Китайское имя Подделка межсайтового запроса, злоумышленник побуждает жертву войти на сторонний веб-сайт, а на стороннем веб-сайте отправляет межсайтовый запрос на атакуемый веб-сайт. Используя регистрационные данные, которые жертва получила на атакованном веб-сайте, аутентификация пользователя в фоновом режиме обходится, и достигается цель выдачи себя за пользователя для выполнения операции на атакуемом веб-сайте.

Краткое введение в процесс атаки CSRF:

  • 1. Жертва заходит на целевой сайт А;
  • 2. Жертва каким-то образом подвергается воздействию ссылки вредоносного веб-сайта B;
  • 3. Жертва нажимает на ссылку, чтобы посетить веб-сайт B, код js на веб-сайте B выполняется, и запрос тайно отправляется на целевой веб-сайт A;
  • 4. Поскольку жертва вошла на веб-сайт А, запрос содержит соответствующие учетные данные cookie веб-сайта А, и окончательный запрос успешно выполнен;

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

Этот процесс хорошо изучен, а место ограничено, поэтому я не буду давать здесь подробного объяснения.

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

  • Это очень просто для запросов GET,imgСсылки тегов не подлежат кросс-доменным ограничениям со стороны браузеров, поэтому запросы можно делать напрямую в виде img;
  • Для запросов POST по-прежнему легко реализовать метод CORS;

2. Защита

Зная весь процесс атаки, мы можем начать видеть, на каких этапах мы можем защититься от CSRF-атак.

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

1. Файлы cookie того же сайта

Если запрос, инициированный третьей стороной, не может содержать соответствующий файл cookie, то все проблемы кажутся решенными. К счастью, браузеры поддерживают файлы cookie.SameSite, что указывает на то, что файлы cookie не отправляются с запросами из разных источников. Это предложение было предложено Google, но ложка дегтя в том, что оно все еще находится на стадии испытаний, и есть проблемы с совместимостью.

2. Токен CSRF

Поскольку браузер не может помочь нам решить все проблемы на данный момент, нам нужно найти способ усложнить механизм проверки личности.Только cookie не гарантирует безопасность, поэтому нам нужно добавить еще одно измерение проверки. Токен SCRF является одним из таких решений.

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

3. Гомологичное обнаружение

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

Refererа такжеOriginЭто одно из полей заголовка http-запроса, которое используется для указания страницы, с которой связан запрос. Таким образом, фоновый сервер может избежать CSRF-атак со сторонних веб-сайтов, проверяя, является ли поле ссылкой со своего собственного веб-сайта. Однако надежность обнаружения одного и того же источника невысока, например, при использовании 302 редиректа для защиты источника http-запрос не будет передаваться.Originполе, покаRefererПоля ограничены правилом Referer Policy и не отправляются.

4. Добавьте дополнительную проверку

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

3. Некоторые случаи

1) Google Digital Garage — онлайн-образовательный продукт компании Google, иностранного инженера по безопасности в своейблогОписывает, как удалить личный кабинет сайта с помощью CSRF-атаки.

2)эта статьяВ нем представлены дыры в безопасности на веб-сайте facebook и способы обхода защиты с помощью CSRF для захвата учетной записи.

XS-Leaks

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

1. Что такое XS-Leaks?

XS-Leaks — это межсайтовые утечки. XS-Leaks использует механизм запросов к кешу HTTP и выводит соответствующую информацию о текущем пользователе, оценивая кеш ресурсов. Если вы впервые услышали о XS-Leaks, то я думаю, вы должны быть удивлены, почему обычное HTTP-кеширование ресурсов также может привести к утечке информации о пользователях.

Команда браузера Chrome опубликовала на своем сайте разработчикастатья, указывает, что браузеры после версии 86 начнут управлять разделом (доменным именем) механизма ресурсов кэша запросов, поскольку предыдущий механизм кэширования может привести к утечке конфиденциальности.

До этого стратегия кэширования запросов браузера Chrome была очень простой:

  • 1. Пользователь посещает страницу А и запрашивает ресурс изображения. После того, как браузер получит изображение, он кэширует изображение и использует URL-адрес изображения в качестве ключевого значения запроса кеша;
  • 2. Затем пользователь посещает страницу B. Если эта страница также использует изображение выше, браузер сначала запрашивает, был ли ресурс кэширован.Поскольку изображение было кэшировано, браузер напрямую использует кэшированный ресурс;

Поскольку для кешированных ресурсов нет ограничений на доменное имя, все веб-сайты совместно используют кешированные ресурсы, поэтому его можно использовать для определения того, посещал ли пользователь определенный веб-сайт: вредоносный веб-сайт может сделать вывод, получен ли ресурс из кеша, инициируя определенный ресурс. запросить историю просмотров пользователя. Например, если я запрашиваю изображение ЛОГОТИПА Nuggets (или других более уникальных ресурсов) на моем веб-сайте, если я считаю, что это изображение из кеша, то я могу знать, что пользователь посетил веб-сайт Nuggets.

По аналогии с описанным выше принципом XS-Leaks использует механизм запроса HTTP-кэша и получает некоторые пользовательские данные, определяя, имеет ли запрос результат. Основные этапы атаки XS-Leaks следующие:

  • 1. Удалить кешированные ресурсы определенного веб-сайта.
  • 2. Заставьте браузер обновить веб-сайт.
  • 3. Проверьте, кэширует ли браузер ресурс, удаленный в (1).

Возьмем маленький каштан, если мы хотим знать, является ли пользователь, посещающий наш сайт в данный момент, сайтом социальной сети (при условии, что ссылкаxxx.com) пользователь с ником `@helloWorld`, что мне делать с атакой XS-Leaks?

Во-первых, мы можем назвать@helloWorldИзображение аватара пользователя взято с сайта социальной сети, при условии, что ссылка на изображение имеет такую ​​длину:http://xxx.com/user/helloWorld.jpg.

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

FETCH POST http://xxx.com/user/helloWorld.jpg

Правильно, инициировав POST-запрос, можно очистить кеш браузера от этого изображения (заинтересованные друзья могут глянутьэта статья).

Далее черезiframeили<link ref=rerender href="http://xxx.com/user" />и другие методы, чтобы незаметно инициировать запрос на посещение страницы личной информации сайта социальной сети.http://xxx.com/user(Эта страница содержит изображение профиля пользователя).

Тогда вам просто нужно снова запросить аватарhttp://xxx.com/user/helloWorld.jpg, чтобы определить, пришло ли оно из кеша, если да, то это не означает, что только что запрошенная страница личной информации содержит это изображение, и можно сделать вывод, что пользователь@helloWorld.

Тогда снова встает вопрос: как судить, что запрос идет из кеша?

Существует еще много методов, один из которых заключается в том, чтобы определить, получено ли изображение из кеша, читая атрибуты ширины и высоты img:

const img = new Image();
img.onload = () => {
  // 如果img不是来自缓存，那么只有在图片加载完成触发onload之后，才能拿到实际的witdh值
  console.log(img.width);
}
img.src = 'http://xxx.com/user/helloWorld.jpg';
// 如果存在缓存，在这里可以立即读取到图片的 witdh 值，否则会打印 0
console.log(img.width);

На данный момент атака XS-Leaks завершена. Мы также можем запросить некоторые привилегированные ссылки, чтобы определить, имеет ли пользователь привилегированную личность на веб-сайте и т. д. Хотя этот маленький каштан не кажется вредным, он просто соединяет текущего пользователя и целевой аккаунт веб-сайта, но не стоит недооценивать дыры в мозгу хакеров, незаметная на первый взгляд лазейка может принести огромные убытки.

Здесь, чтобы поделиться с вами о XS-Leaksгитхаб-адрес, в котором записываются методы атак, знания и практические примеры, связанные с XS-Leaks, чтобы помочь каждому глубже понять концепции и методы атак.

2. Защита

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

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

  • Установите файлы cookie SameSite;
  • CSRF Token;
  • Браузер поддерживает раздел кеша;

3. Атака на кэш веб-сервера

XS-Leaks использует уязвимость кеша браузера для проведения атаки, но на самом деле кешировать может не только браузер, но и веб-сервер.Кэш сервера предназначен для временного хранения запрошенных ресурсов в специальном кэш-сервере (например, CDN). ), когда следующий пользователь обращается к тому же ресурсу, ответ может быть получен непосредственно с кэш-сервера, что снижает нагрузку на веб-сервер.

Тогда, если мы сможем каким-то образом поместить код атаки в кэш-сервер, такой как CDN, то пользователи, которые инициируют тот же запрос ресурсов, получат вредоносный код и будут атакованы, что не реализует тип «хранилище XS-Leaks». атака"?

кеш-сервер черезcache-keyчтобы определить, имеют ли два пользователя доступ к одному и тому же ресурсу, и этоcache-keyОбычно состоит из метода запроса, пути, запроса, заголовка хоста. Предположим, веб-сервер отвечает следующим запросом:

Ответ будет включать заголовок запросаX-Forwarded-HostЗначение напрямую встраивается в атрибут содержимого метатега, что создает уязвимость к XSS-атакам, поэтому мы инициируем запрос следующим образом:

GET /en?dontpoisoneveryone=1 HTTP/1.1
Host: www.redhat.com
X-Forwarded-Host: a."><script>alert(1)</script>

Сервер вернет следующий ответ и закэширует его в кэш-сервере:

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<meta property="og:image" content="https://a."><script>alert(1)</script>"/>

из-заX-Forwarded-HostНе принадлежитcache-keyчасть , поэтому, когда другие пользователи инициируют/enПри выполнении запроса сервер будет думать, что он запрашивает тот же ресурс для применения стратегии кэширования, и напрямую ответит на вышеуказанный злонамеренный ответ пользователю, вызвав атаку.

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

скажи что-нибудь еще

Несмотря на то, что было предпринято так много мер для борьбы с различными атаками в Интернете и защиты от них, хакеры обнаруживают и устраняют одну за другой дыры в безопасности. подвергается атаке в 2019 году. А вот и XSS-атака. Для этой атаки требуется всего одна строка кода:

<noscript><p title="</noscript><img src=x onerror=alert(1)>">

Общая причина заключается в том, что Google использует предоставленный HTML при экранировании вставленного текста.templateэтикетка, использованиеtemplateявляется хорошим выбором, поскольку его можно использовать для анализа HTML без запуска выполнения сценария JavaScript во время процесса анализа. ОднакоtemplateЭто среда с отключенным JavaScript, и синтаксический анализ noscript в среде, где JavaScript разрешен и запрещен, отличается, что приводит к риску этого вредоносного кода после синтаксического анализа и дезинфекции и, наконец, к успешной реализации атаки XSS. Заинтересованные друзья могут прочитать этоСтатья об этой XSS-атаке.

На самом деле существует много подобных «боковых» методов атаки, таких как те, которые мы часто используем.SVGДля изображений структура SVG очень похожа на структуру HTML.forginObjectэтикетку мы также можем поставитьscriptИли другие теги HTML вставляются в изображения SVG.Если веб-сервер позволяет пользователям загружать произвольные изображения SVG, существует риск постоянных атак XSS. Экранирование HTML иногда не выполняется с помощью одной или двух строк кода.Когда мы сталкиваемся с похожими текстовыми редакторами, которым необходимо сохранить стиль вставляемого пользователем контента, то, как избежать риска XSS при сохранении этого HTML, стоит нашего тщательного проектирования.

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

На самом деле, когда я использовал веб-сайт, чтобы сделать две диаграммы взаимодействия в предыдущей главе онлайн, я «непреднамеренно» активировалimgКод напрямую вызывает диалоговое окно, которое также показывает со стороны, что веб-безопасности не уделялось должного внимания во многих командах разработчиков.Однако многие случаи атак говорят нам о том, что после атаки на наш веб-сайт потеря может быть невозможной. Таким образом, мы не можем просто говорить о веб-безопасности, говорить о ней на бумаге или просто использовать ее в качестве отправной точки для интервью, но мы всегда должны быть бдительными, и тревожный звонок прозвенит.

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

Справочная статья

Серия Front-end Security (1): как предотвратить XSS-атаки?

Анализ шести распространенных атак и средств защиты веб-безопасности

HTTP Cache Cross-Site Leaks

Gaining security and privacy by partitioning the cache

Отравление веб-кэша

Категории