Веб-интерфейс безопасности — XSS и CSRF

Безопасность
Веб-интерфейс безопасности — XSS и CSRF

XSS

XSS (Cross-site scripting) относится к атаке с использованием межсайтовых сценариев. Злоумышленник внедряет код на страницу А для достижения цели кражи информации. Суть в том, что данные выполняются как программа. XSS очень вреден.Как правило, XSS может делать следующие вещи:

  • Получить данные страницы, включая dom, куки, localStorage и т. д.
  • Взлом логики внешнего интерфейса
  • послать запрос
  • ...

1 типы XSS

  • Отражающий (непостоянный): прямая инъекция через параметры URL.
  • Тип хранилища (постоянный): Внедрить при чтении после сохранения в базе данных
  • На основе DOM: исполняемый вредоносный скрипт изменяет структуру скрипта страницы.

2 точки впрыска XSS

  • Содержимое или атрибуты узла HTML
  • код javascript
  • богатый текст

3 XSS-защита

3.1 Защита браузера

Защита связана с "X-XSS-Protection". Значение по умолчанию равно 1, то есть по умолчанию включена защита XSS, которая может защищать от отражающих XSS, но ее функция ограничена. Она может защищать только от XSS, внедренного в Содержимое узла HTML или атрибуты, такие как параметры URL, содержат теги сценария. Не рекомендуется полагаться исключительно на эту защиту.

3.2 Защита содержимого узла HTML

Код риска:

<template>
    <p>{{username}}</p>
</template>

<script>
    username = "<script>alert('xss')</script>"
</script>

Скомпилированный код:

<p>
    <script>alert('xss')</script>
</p>

В приведенном выше примере используется синтаксис vue, но на самом деле в такой среде, как vue, содержимое в {{username}} является строковым, поэтому оно не будет выполняться браузером.Если вы перейдете на другие языки шаблонов, такие как jade , то возможны риски. То же ниже.

Код защиты:

убегая<для&ltтак же как>для&gtдля реализации защиты от содержимого узла HTML.

<template>
    <p>{{username}}</p>
</template>
<script>
    escape = function(str){
        return str.replace(/</g, '&lt;').replace(/>/g, '&gt;')
    }
    username = escape("<script>alert('xss')</script>")
</script>

3.3 Защита атрибутов HTML

<template>
    <img :src="image" />
</template>
<script>
    image = 'www.a.com/c.png" onload="alert(1)'
</script>

Скомпилированный код:

<img src="www.a.com/c.png" onload="alert(1)" />

Код защиты:

убегая"для&quto;,'для&#39;Для обеспечения защиты пробелы обычно не экранируются, но для этого атрибуты должны быть заключены в кавычки!

<template>
    <img :src="image" />
</template>
<script>
    escape = function(str){
        return str.replace(/"/g, '&quto;').replace(/'/g, '&#39;').replace(/ /g, '&#32;')
    }
    image = escape('www.a.com/c.png" onload="alert(1)')
</script>

3.4 Защита от кода JavaScript

Предположим, что адрес страницы доступаwww.a.com?id=1";alert(1);"

Код риска:

var id = getQuery('id')

Скомпилированный код:

var id = "1";alert(1);""

Код защиты:

Путем сериализации данных в JSON

escape = function(str){
    return JSON.stringify(str)
}

3.5 Защита от форматированного текста

Код риска:

<template>
    <p v-html="richTxt"></p>
</template>

<script>
    richTxt = '<a onmouseover=alert(document.cookie)>点击</a>'
</script>

В приведенном выше коде, когда мышь перемещается над «щелчком», будет запущено всплывающее окно с предупреждением! Это происходит во вью.

Защита форматированного текста — сложный проект, поскольку форматированный текст может содержать HTML и скрипты, которые трудно предсказать и защитить. Рекомендуется фильтровать разрешенные HTML-теги и атрибуты тегов для защиты с помощью белого списка. Примерная реализация выглядит следующим образом:

  • Преобразование фрагментов HTML-кода в данные на уровне дерева
  • Пройдитесь по каждому узлу дерева, отфильтруйте типы и атрибуты узлов или выполните специальную обработку.
  • После обработки преобразовать древовидную структуру в HTML-код.

Конечно, это также можно реализовать с помощью сторонних библиотек с открытым исходным кодом, подобныхjs-xss.

3.6 Политика безопасности контента CSP

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

CSP может передавать заголовок HTTP (Content-Security-Policy) или<meta>Этот элемент настраивает политику безопасности содержимого страницы, чтобы контролировать, какие ресурсы браузер может получить для этой страницы. Например, страница, которая может загружать файлы и отображать изображения, должна разрешать получение изображений из любого места, но ограничивать атрибут действия формы только указанной конечной точкой. Правильно разработанная политика безопасности контента должна эффективно защищать страницы от атак с использованием межсайтовых сценариев.

Описание конкретной конфигурации можно переместитьMDN

4 О защите от xss в vue

Vue уже реализовал некоторую защиту от xss в фреймворке.Для некоторого стороннего контента (такого как интерфейс или параметры URL) мы пытаемся использовать выражения {{ }} для отображения, потому что контент в {{ }} является строковым, браузер не действует на содержимое в нем.

Используйте команду v-hmtl как можно реже или сначала выполните фильтрацию xss для содержимого. несмотря на то чтоHTML 5 указывает не выполнять теги «скрипт», вставленные innerHTML.Но у тегов могут быть функции слушателя, которые выполняют javascript, такие как onload, onerror, onmouseover и так далее.

Два CSRF

CSRF (подделка межсайтовых запросов) относится к подделке межсайтовых запросов. В отличие от XSS, XSS — это злоумышленник, который напрямую внедряет атаки на наш веб-сайт A, а CSRF — это поддельный запрос на наш веб-сайт A через веб-сайт B.

Например, после того, как вы войдете на веб-сайт покупок А и щелкнете по вредоносной ссылке Б, Б запрашивает интерфейс оформления заказов веб-сайта А, и в результате ваша учетная запись на веб-сайте А фактически сгенерирует заказ. Принцип, лежащий в основе этого: веб-сайт B подделывает запрос веб-сайта A через форму и получает запрос.В это время запрос принесет файлы cookie веб-сайта A. Если состояние входа в систему сохраняется в файлах cookie, реализуется атака подделки .

1 Опасности CSRF

  • Статус входа пользователя украден
  • Выполнять бизнес-запросы
  • ......

2 Особенности CSRF

  • Поддельные запросы не проходят через сайт А
  • Доменное имя поддельного запроса не является сайтом А

3 Защита CSRF

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

3.1 Добавьте проверочный код

Особенностью CSRF является то, что伪造请求不经过网站A, то мы можем увеличить средства проверки веб-сайта А, такие как добавление графического кода подтверждения или кода подтверждения SMS и т. д., только проверенный запрос является законным. Но у этого решения есть два ограничения: одно — увеличить стоимость разработки, а другое — ухудшить взаимодействие с пользователем.

3.2 настройки файлов cookie

Для второй характеристики CSRF伪造请求的域名不是网站A, то цель защиты достигается за счет ограничения использования файлов cookie другими веб-сайтами с доменными именами. Конкретный подход заключается в следующем:

cookies设置sameSite属性的值为strict，这样只有同源网站的请求才会带上cookies。但是此方案有浏览器兼容问题。

3.3 Проверка реферера

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

后端可以根据HTTP请求头的`referer`来判断请求是否来自可信任网站。但是这个方案也有局限性，攻击者可以设置请求不携带referer，所以这个方案适合用于辅助。

3.4 Проверка токена csrf

Это одно из относительно зрелых решений в настоящее время.Конкретный подход:

服务端随机生成token，保存在服务端session中，同时保存到客户端中，客户端发送请求时，把token带到HTTP请求头或参数中，服务端接收到请求，验证请求中的token与session中的是否一致。

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

3.5 Замена схемы состояния входа в систему

Поскольку CSRF, по сути, является поддельным запросом, содержащим информацию, хранящуюся в файлах cookie, это не очень хорошо для состояния входа в систему механизма сеанса.Если схема JWT (JSON Web Token) заменена, информация о токене обычно устанавливается в заголовок HTTP, поэтому CSRF можно защитить от атаки.

Он не расширяется здесь для преимуществ и недостатков двух государств входа.

Три постскриптума

Здесь представлены сведения о XSS и CSRF.Если вы хотите узнать о внешней безопасности, отличной от XSS и CSRF, вы можете нажать на младшего брата этой статьи:

Веб-интерфейс безопасности - безопасность файлов cookie, защита паролей, перехват кликов

Категории