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

предисловие

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

Если вы хотите прочитать больше оригинальных статей высокого качества, пожалуйста, нажмитеБлог GitHub

1. XSS

XSS (Cross-Site Scripting), атака с использованием межсайтовых сценариев, может называться только XSS, потому что аббревиатура и CSS перекрываются. Атака с использованием межсайтовых сценариев относится к атаке, осуществляемой путем запуска незаконных тегов HTML или JavaScript в браузерах зарегистрированных пользователей веб-сайтов с уязвимостями безопасности.

Атаки с использованием межсайтовых сценариев могут иметь следующие последствия:

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

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

Методы XSS-атак постоянно меняются, но их можно условно разделить на несколько типов.

1. Непостоянный XSS (отраженный XSS)

Непостоянные уязвимости XSS, обычно путем отправки другимURL-адреса с параметрами кода вредоносного скрипта, при открытии URL-адреса уникальные параметры вредоносного кода анализируются и выполняются с помощью HTML.

Например, если на странице есть следующий код:

<select>
    <script>
        document.write(''
            + '<option value=1>'
            +     location.href.substring(location.href.indexOf('default=') + 8)
            + '</option>'
        );
        document.write('<option value=2>English</option>');
    </script>
</select>

Злоумышленник может напрямую передать URL-адрес (что-то вроде:https://xxx.com/xxx?default=<script>alert(document.cookie)</script>) для внедрения кода исполняемого скрипта. Однако некоторые браузеры, такие как Chrome, имеют встроенные XSS-фильтры, которые могут предотвратить большинство отраженных XSS-атак.

Непостоянные эксплойты XSS имеют следующие характеристики:

Немедленно, без серверного хранилища, атака может быть завершена напрямую через HTTP-запросы GET и POST для получения данных о конфиденциальности пользователя.
Злоумышленнику необходимо обмануть щелчок, и он должен быть инициирован пользователем, нажимающим на ссылку.
Низкий уровень обратной связи, что затрудняет обнаружение и реагирование на исправления
Украсть важную и конфиденциальную информацию пользователя

Чтобы предотвратить непостоянные уязвимости XSS, вам необходимо убедиться в нескольких вещах:

Все содержимое или визуализированные данные, отображаемые веб-страницей, должны поступать с сервера.
попробуй неURL,document.referrer,document.formsПодождите, пока данные, полученные из этого DOM API, будут обработаны напрямую.
попробуй не использоватьeval, new Function(),document.write(),document.writeln(),window.setInterval(),window.setTimeout(),innerHTML,document.createElement()и другие методы для исполняемых строк.
Если вы не можете выполнить перечисленные выше пункты, вы также должны экранировать строковые параметры, передаваемые в методы, включающие рендеринг DOM.
При внешнем рендеринге вам нужно выполнить escape-кодирование для любого поля.

2. Постоянный XSS (сохраненный XSS)

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

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

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

Успешная атака требует одновременного выполнения следующих условий:

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

Постоянный XSS имеет следующие характеристики:

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

3. Как защищаться

Обычно есть два способа защиты от XSS-атак.

1) CSP

CSP по существу устанавливает белый список, и разработчик явно сообщает браузеру, какие внешние ресурсы могут быть загружены и выполнены. Нам нужно только настроить правила, как перехват реализуется самим браузером. Таким образом мы можем минимизировать XSS-атаки.

Обычно есть два способа включить CSP:

Установите Content-Security-Policy в заголовке HTTP
Как установить метатеги

Вот пример настройки заголовка HTTP:

Разрешить загрузку ресурсов только с этого сайта

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

Разрешить загрузку только изображений протокола HTTPS

Content-Security-Policy: img-src https://*

Разрешить загрузку любого исходного кадра

Content-Security-Policy: child-src 'none'

Дополнительные свойства см.Документация по политике безопасности контента

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

2) Экранирующий символ

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

function escape(str) {
  str = str.replace(/&/g, '&amp;')
  str = str.replace(/</g, '&lt;')
  str = str.replace(/>/g, '&gt;')
  str = str.replace(/"/g, '&quto;')
  str = str.replace(/'/g, '&#39;')
  str = str.replace(/`/g, '&#96;')
  str = str.replace(/\//g, '&#x2F;')
  return str
}

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

const xss = require('xss')
let html = xss('<h1 id="title">XSS Demo</h1><script>alert("xss");</script>')
// -> <h1>XSS Demo</h1>&lt;script&gt;alert("xss");&lt;/script&gt;
console.log(html)

В приведенном выше примере для реализации используется js-xss, вы можете видеть, что тег h1 сохраняется в выходных данных, а тег скрипта фильтруется.

3) HTTP-файлы cookie.

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

2. CSRF

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

1. Принцип атаки CSRF

Давайте сначала представим принцип атаки CSRF:

Для завершения атаки CSRF необходимо выполнить три условия:

Пользователь вошел на сайт А, и файл cookie записывается локально.
Не выходя из системы с сайта А (то есть с действующими файлами cookie), пользователь посещает опасный сайт Б (сайт Б требует доступа к сайту А), предоставленный злоумышленником.
Сайт A не выполняет никакой защиты от CSRF

Давайте рассмотрим пример: когда мы заходим на страницу переноса, у нас вдруг загораются глазаУдивлен, обнаружив ссылку «ХХХ личные фото, не смотри и пожалеешь на всю жизнь», не выдержал беспокойства и сразу кликнул на опасный сайт (код страницы показан на рисунке ниже), но при загрузке страницы выполнитсяsubmitFormЭтот метод используется для отправки запроса на передачу 10 блоков хакеру.

2. Как защищаться

Для предотвращения CSRF-атак можно соблюдать следующие правила:

Запросы Get не изменяют данные
Запретить сторонним сайтам доступ к пользовательским файлам cookie
Интерфейс запроса блокировки стороннего веб-сайта
Запрос сопровождается проверочной информацией, такой как проверочный код или токен.

1) SameSite

Атрибут SameSite можно установить для файлов cookie. Этот атрибут указывает, что файлы cookie не отправляются с междоменными запросами, что может значительно уменьшить атаки CSRF, но в настоящее время этот атрибут совместим не со всеми браузерами.

2) Referer Check

HTTP Referer является частью заголовка Когда браузер отправляет запрос на веб-сервер, он обычно передает информацию Referer, чтобы сообщить серверу, с какой страницы он связан, и сервер может получить некоторую информацию для обработки. От CSRF-атак можно защититься, изучив источник запроса. Реферер обычного запроса имеет определенные правила, например, реферер, который отправляет форму, должен быть запросом, инициированным на странице. такОпределите, является ли это атакой CSRF, проверив, является ли значение реферера заголовка http этой страницей..

Однако в некоторых случаях, например при переходе с https на http, браузер не будет отправлять реферер из соображений безопасности, и сервер не сможет его проверить. Если другие веб-сайты в том же домене, что и веб-сайт, имеют XSS-уязвимости, злоумышленник может внедрить вредоносные скрипты на другие веб-сайты, и жертва также будет атакована, если жертва войдет на такой веб-сайт в том же домене. По вышеуказанным причинам нельзя полностью полагаться на Referer Check как на основное средство защиты от CSRF. Однако возникновение CSRF-атак можно отслеживать с помощью Referer Check.

3) Anti CSRF Token

В настоящее время более полным решением является присоединение к Anti-CSRF-Token. То есть при отправке запроса в качестве параметра HTTP-запроса добавляется случайно сгенерированный токен, а на сервере устанавливается перехватчик для проверки токена. Сервер считывает значение маркера в файле cookie текущего домена браузера и проверяет, существуют ли и равны ли маркер в запросе и значение маркера в файле cookie, и считает это законным запросом. В противном случае запрос считается незаконным и в услуге отказывается.

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

4) Код подтверждения

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

3. Нажмите Взлом

Clickjacking — это атака визуального обмана. Злоумышленник встраивает атакуемый веб-сайт в свою веб-страницу, встраивая iframe, и делает iframe прозрачным, открывая кнопку на странице, чтобы побудить пользователей щелкнуть.

1. Особенности

Высокий уровень сокрытия, обман пользователей для работы
«Атака с наложением пользовательского интерфейса»
Используйте iframe или другие атрибуты тега

2. Принцип кликджекинга

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

iframe {
width: 1440px;
height: 900px;
position: absolute;
top: -0px;
left: -0px;
z-index: 2;
-moz-opacity: 0;
opacity: 0;
filter: alpha(opacity=0);
}
button {
position: absolute;
top: 270px;
left: 1150px;
z-index: 1;
width: 90px;
height:40px;
}
</style>
......
<button>点击脱衣</button>
<img src="http://pic1.win4000.com/wallpaper/2018-03-19/5aaf2bf0122d2.jpg">
<iframe src="http://i.youku.com/u/UMjA0NTg4Njcy" scrolling="no"></iframe>

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

3. Как защищаться

1) ОПЦИИ X-FRAME

X-FRAME-OPTIONS— это заголовок ответа HTTP с хорошей поддержкой в современных браузерах. Этот заголовок HTTP-ответа предназначен для защиты от атак кликджекинга, вложенных в iframe.

Заголовок ответа имеет три необязательных значения:

DENY означает, что страница не может отображаться через iframe
SAMEORIGIN, указывающий, что страница может отображаться в iframe под тем же доменным именем
РАЗРЕШЕНИЕ ОТ, указывающее, что страница может отображаться в iframe указанного источника.

2) Защита JavaScript

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

<head>
  <style id="click-jack">
    html {
      display: none !important;
    }
  </style>
</head>
<body>
  <script>
    if (self == top) {
      var style = document.getElementById('click-jack')
      document.body.removeChild(style)
    } else {
      top.location = self.location
    }
  </script>
</body>

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

4. Уязвимость перехода по URL-адресу

Определение: проблема безопасности, вызванная направлением приложения в небезопасную стороннюю область с помощью перенаправления URL-адресов без проверки подлинности.

1. Принцип уязвимости перехода по URL

Хакеры используют уязвимости перехода по URL-адресам, чтобы побудить пользователей с низким уровнем безопасности щелкнуть, что приводит к утечке информации о пользователе или потере средств. Принцип заключается в том, что хакеры создают вредоносные ссылки (ссылки должны быть замаскированы, чтобы они были как можно более запутанными) и размещают их в группах QQ или в барах/форумах с большим количеством просмотров страниц. После того, как пользователь с низким уровнем безопасности щелкает, он анализируется сервером или браузером, а затем переходит на вредоносный веб-сайт.

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

Например, если вы замаскируете URL-адрес, как показано ниже, сможете ли вы идентифицировать его как вредоносный URL-адрес?

http://gate.baidu.com/index?act=go&url=http://t.cn/RVTatrd
http://qt.qq.com/safecheck.html?flag=1&url=http://t.cn/RVTatrd
http://tieba.baidu.com/f/user/passport?jumpUrl=http://t.cn/RVTatrd

2. Реализация:

Прыжок заголовка
Джаваскрипт прыжок
Прыжок по мета-тегу

Здесь мы даем метод реализации перехода по заголовку:

<?php
$url=$_GET['jumpto'];
header("Location: $url");
?>

http://www.wooyun.org/login.php?jumpto=http://www.evil.com

Здесь пользователи будут думатьwww.wooyun.orgдоверяют, но нажатие на приведенную выше ссылку приведет к тому, что пользователь в конечном итоге посетитwww.evil.comэтот вредоносный URL.

3. Как защищаться

1) Ограничение реферера

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

2) Добавить токен подтверждения действительности

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

5. SQL-инъекция

SQL-инъекция — это распространенная уязвимость веб-безопасности, которая позволяет злоумышленникам получать доступ к данным или изменять их, а также использовать потенциальные уязвимости базы данных.

1. Принцип внедрения SQL

Давайте возьмем пример мастер-ключа, чтобы проиллюстрировать его принцип:

<form action="/login" method="POST">
    <p>Username: <input type="text" name="username" /></p>
    <p>Password: <input type="password" name="password" /></p>
    <p><input type="submit" value="登陆" /></p>
</form>

Внутренний оператор SQL может выглядеть следующим образом:

let querySQL = `
    SELECT *
    FROM user
    WHERE username='${username}'
    AND psw='${password}'
`;
// 接下来就是执行 sql 语句...

Это страница входа, которую мы часто видим, но если злоумышленник вводит имя пользователя,admin' --, введите пароль по желанию, и вы сможете напрямую войти в систему. почему!---Это SQL-инъекция

Оператор SQL, который мы представили ранее, был таким:

SELECT * FROM user WHERE username='admin' AND psw='password'

Но злоумышленники используют странные имена пользователей, чтобы изменить вашу инструкцию SQL в следующую форму:

SELECT * FROM user WHERE username='admin' --' AND psw='xxxx'

В SQL,' --Это означает закрытие и комментирование, -- означает содержимое, стоящее за комментарием, поэтому оператор запроса становится таким:

SELECT * FROM user WHERE username='admin'

Так называемый универсальный пароль — это, по сути, способ использования SQL-инъекций.

Процесс внедрения SQL включает в себя следующие процессы:

Получить параметры запроса пользователя
вставлен в код
Оператор SQL был успешно выполнен в соответствии с семантикой наших сконструированных параметров.

Предпосылки для внедрения SQL: 1. Может контролировать входные данные 2. Код, который должен выполняться сервером, сращивается с управляющими данными.

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

2. Опасность

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

3. Как защищаться

Строго ограничить права доступа к базе данных веб-приложения, предоставить этому пользователю минимальные привилегии, которые только могут удовлетворить его работу, тем самым минимизировать вред инъекционных атак на базу данных
Бэкэнд-код проверяет, что входные данные соответствуют ожиданиям., строго ограничивайте типы переменных, например, используйте регулярные выражения для некоторой обработки сопоставления.
Экранирование специальных символов (', ", \, , &, *, ; и т. д.), поступающих в базу данных, или преобразование кодировки. В основном все языки бэкенда имеют методы экранирования строк, такие как библиотека lodash._escapehtmlchar от lodash.
Рекомендуется использовать параметризованный интерфейс запросов, предоставляемый базой данных, для всех операторов запросов., параметризованные операторы используют параметры вместо встраивания пользовательских входных переменных в оператор SQL, т. е. не объединяют оператор SQL напрямую. Например, параметр-заполнитель ? в методе запроса библиотеки mysqljs в Node.js.

6. Атака путем внедрения команд ОС

Внедрение команд ОС похоже на внедрение SQL, за исключением того, что внедрение SQL предназначено для базы данных, а внедрение команд ОС — для операционной системы. Атаки с внедрением команд ОС относятся к выполнению незаконных команд операционной системы через веб-приложения для достижения цели атак. Пока вы можете вызывать функции оболочки, существует риск быть атакованным. Если есть упущение при вызове оболочки, вставленная недопустимая команда может быть выполнена.

Атаки с внедрением команд могут отправлять команды в оболочку для запуска программ из командной строки операционной системы Windows или Linux. То есть различные программы, установленные в операционной системе, могут выполняться с помощью атак с внедрением команд.

1. Принцип

Хакер создает команду и отправляет ее в веб-приложение. Веб-приложение извлекает команду, созданную хакером, и встраивает ее в исполняемую команду. Поскольку команда, введенная хакером, нарушает исходную структуру команды, веб-приложение выполняет дополнительные команды. Наконец, веб-приложение Программа выводит результат выполнения на страницу ответа.

Мы используем пример, чтобы проиллюстрировать принцип Если вам нужно реализовать требование: пользователь отправляет некоторый контент на сервер, а затем выполняет некоторые системные команды на сервере, чтобы вернуть результат пользователю

// 以 Node.js 为例，假如在接口中需要从 github 下载用户指定的 repo
const exec = require('mz/child_process').exec;
let params = {/* 用户输入的参数 */};
exec(`git clone ${params.repo} /some/path`);

еслиparams.repoвходящийhttps://github.com/admin/admin.github.io.gitОн действительно может загрузить нужный код из указанного репозитория git. но еслиparams.repoвходящийhttps://github.com/xx/xx.git && rm -rf /* &&Так уж получилось, что ваш сервис запущен с привилегиями root.

2. Как защищаться

Серверная часть накладывает правила (такие как регулярные выражения) на содержимое, отправляемое внешним интерфейсом.
Выполнять экранирование параметров командной строки для всех входящих параметров перед вызовом системных команд.
Не соединяйте операторы команд напрямую, используйте некоторые инструменты для объединения и обхода предварительной обработки, такие как Node.js.shell-escape npmСумка

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

использованная литература

Сводка распространенных атак и средств защиты веб-безопасности
предварительное интервью
Графический HTTP
Как много вы знаете о веб-безопасности
кликджекинг веб-безопасности (кликджекинг)
Уязвимость перенаправления URL/перехода
Веб-белая шляпа Netease