Говоря о XSS и CSRF

В области веб-безопасности наиболее распространенными методами атак являются XSS и CSRF. В этой статье кратко представлены атаки и защита XSS и CSRF.

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

XSS

XSS, то есть Cross Site Script, — это атака с использованием межсайтового скриптинга на китайском языке, ее исходная аббревиатура — CSS, но для того, чтобы отличить ее от каскадных таблиц стилей, в области безопасности она называется XSS.

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

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

Атаки XSS можно разделить на 3 категории: отражающие (непостоянные), хранимые (постоянные) и основанные на DOM.

Светоотражающий

Отраженный XSS просто «отражает» данные, введенные пользователем в браузере.Этот метод атаки часто требует от злоумышленника побудить пользователя щелкнуть вредоносную ссылку, отправить форму или войти на вредоносный веб-сайт злоумышленника.

См. пример. Сначала я готовлю статическую страницу следующим образом:

Адрес вредоносной ссылки указывает наlocalhost:8001/?q=111&p=222. Затем я запускаю простую службу Node для обработки вредоносных запросов на ссылки:

const http = require('http');
function handleReequest(req, res) {
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'});
    res.write('<script>alert("反射型 XSS 攻击")</script>');
    res.end();
}

const server = new http.Server();
server.listen(8001, '127.0.0.1');
server.on('request', handleReequest);

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

Это создает отраженную атаку XSS. Злоумышленники могут внедрять произвольные вредоносные сценарии для атаки, возможно вредоносные сценарии или сценарии, которые могут получать личные данные пользователя (например, файлы cookie), в зависимости от цели злоумышленника.

тип хранения

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

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

Возьмите пример.

Сначала подготовьте страницу ввода:

<input type="text" id="input">
<button id="btn">Submit</button>   

<script>
    const input = document.getElementById('input');
    const btn = document.getElementById('btn');

    let val;
     
    input.addEventListener('change', (e) => {
        val = e.target.value;
    }, false);

    btn.addEventListener('click', (e) => {
        fetch('http://localhost:8001/save', {
            method: 'POST',
            body: val
        });
    }, false);
</script>

Запустите прослушивание службы Nodesaveпросить. Для простоты используйте переменную для хранения пользовательского ввода:

const http = require('http');

let userInput = '';

function handleReequest(req, res) {
    const method = req.method;
    res.setHeader('Access-Control-Allow-Origin', '*');
    res.setHeader('Access-Control-Allow-Headers', 'Content-Type')
    
    if (method === 'POST' && req.url === '/save') {
        let body = '';
        req.on('data', chunk => {
            body += chunk;
        });

        req.on('end', () => {
            if (body) {
                userInput = body;
            }
            res.end();
        });
    } else {
        res.writeHead(200, {'Content-Type': 'text/html; charset=UTF-8'});
        res.write(userInput);
        res.end();
    }
}

const server = new http.Server();
server.listen(8001, '127.0.0.1');

server.on('request', handleReequest);

Когда пользователь нажимает кнопку отправки для ввода информации, отправленной на сервер, серверuserInputПеременные содержат входное содержимое. когда пользователь проходитhttp://localhost:8001/${id}При доступе сервер вернетidСоответствующий контент (данный пример упрощает обработку). Если пользователь вводит содержимое вредоносного сценария, когда другие пользователи получают доступ к содержимому, вредоносный сценарий будет выполняться на стороне браузера:

DOM на основе

Атаки XSS на основе DOM относятся к изменению структуры DOM страницы с помощью вредоносных сценариев, которые являются чисто атаками на стороне клиента.

См. следующий код:

<h2>XSS: </h2>
<input type="text" id="input">
<button id="btn">Submit</button>
<div id="div"></div>
<script>
    const input = document.getElementById('input');
    const btn = document.getElementById('btn');
    const div = document.getElementById('div');

    let val;
     
    input.addEventListener('change', (e) => {
        val = e.target.value;
    }, false);

    btn.addEventListener('click', () => {
        div.innerHTML = `<a href=${val}>testLink</a>`
    }, false);
</script>

нажмитеSubmitПосле нажатия кнопки на текущей странице будет вставлена ссылка с адресом входа пользователя. Если пользователь конструирует следующее при вводе:

'' onclick=alert(/xss/)

После отправки пользователем код страницы становится таким:

<a href onlick="alert(/xss/)">testLink</a>

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

Предотвращение XSS-атак

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

HttpOnly предотвращает захват файлов cookie

HttpOnly был впервые предложен Microsoft и с тех пор стал стандартом. Браузер предотвратит доступ Javascript страницы к файлам cookie с атрибутом HttpOnly.

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

входная проверка

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

В защите от XSS проверка ввода обычно заключается в проверке того, содержат ли данные, введенные пользователем,<,>И другие специальные символы, если они существуют, специальные символы отфильтровываются или кодируются, что также называется XSS Filter.

И в некоторых фронтальных фреймах будет копияdecodingMap, который используется для кодирования или фильтрации специальных символов или тегов, содержащихся в пользовательском вводе, например<,>,script, чтобы предотвратить XSS-атаки:

// vuejs 中的 decodingMap
// 在 vuejs 中，如果输入带 script 标签的内容，会直接过滤掉
const decodingMap = {
  '&lt;': '<',
  '&gt;': '>',
  '&quot;': '"',
  '&amp;': '&',
  '&#10;': '\n'
}

выходная проверка

Будут проблемы с пользовательским вводом и будут проблемы с серверным выводом. Вообще говоря, помимо вывода форматированного текста, когда переменная выводится на HTML-страницу, для защиты от XSS-атак можно использовать кодирование или экранирование. например, используяsanitize-htmlВыходной контент регулярно фильтруется, а затем выводится на страницу.

CSRF

CSRF, или подделка межсайтовых запросов, в китайском переводе это подделка межсайтовых запросов, метод атаки, который перехватывает доверенных пользователей для отправки неожиданных запросов на сервер.

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

Прежде чем привести пример, давайте поговорим о политике браузера в отношении файлов cookie.

Политика использования файлов cookie браузера

Файл cookie – это небольшой фрагмент данных, который сервер отправляет в браузер пользователя и сохраняет его локально. Он будет перенесен и отправлен на сервер при следующем запросе браузера к тому же серверу. Файлы cookie в основном используются для следующих трех аспектов:

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

Браузеры хранят файлы cookie двух типов:

Сеансовый файл cookie (сеансовый файл cookie): сеансовый файл cookie — это самый простой файл cookie. Для него не нужно указывать время истечения срока действия (Expires) или период действия (Max-Age). Он действителен только в течение периода сеанса. После закрытия браузера , он будет автоматически удален.
Постоянный файл cookie (постоянный файл cookie): в отличие от файла cookie сеанса, постоянный файл cookie может указывать определенное время истечения срока действия (Expires) или период действия (Max-Age).

res.setHeader('Set-Cookie', ['mycookie=222', 'test=3333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

Приведенный выше код создает два файла cookie:mycookieа такжеtest, первый является файлом cookie сеанса, а второй — постоянным файлом cookie. Когда мы переходим к просмотру свойств, связанных с файлами cookie, разные браузеры по-разному реагируют на сеансовые файлы cookie.ExpiresЗначение атрибута отличается:

Fire Fox:

Chrome:

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

CSRF-атака через куки

Предположим, есть сайт bbs:http://www.c.com, когда вошедший в систему пользователь инициирует следующий запрос GET, запись, указанная идентификатором, будет удалена:

http://www.c.com:8002/content/delete/:id

если инициированоhttp://www.c.com:8002/content/delete/87343По запросу пост с id 87343 будет удален. Когда пользователь входит в систему, устанавливаются следующие файлы cookie:

res.setHeader('Set-Cookie', ['user=22333; expires=Sat, 21 Jul 2018 00:00:00 GMT;']);

userСоответствующее значение является идентификатором пользователя. Затем создайте страницу A:

<p>CSRF 攻击者准备的网站：</p>
<img src="http://www.c.com:8002/content/delete/87343">

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

Видно, что когда авторизованный пользователь посещает веб-сайт злоумышленника,www.c.comИнициировать запрос на удаление публикации пользователя. В этот момент, если пользователь переключается наwww.c.comОбновите страницу сообщения , вы обнаружите, что сообщение с идентификатором 87343 было удалено.

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

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

Предотвращение CSRF-атак

В настоящее время существуют в основном следующие способы предотвращения CSRF-атак.

проверяющий код

Капча считается наиболее лаконичной и эффективной защитой от CSRF-атак.

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

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

Referer Check

В соответствии с протоколом HTTP в заголовке HTTP есть поле Referer, которое записывает исходный адрес HTTP-запроса. С помощью Referer Check можно проверить, исходит ли запрос из законного «источника».

Например, если пользователь хочет удалить свой собственный пост, он должен сначала войти в систему.www.c.com, затем найдите соответствующую страницу и инициируйте запрос на удаление публикации. На данный момент значение Referer равноhttp://www.c.com; когда запрос сделан изwww.a.comПри инициации значение Referer равноhttp://www.a.com. Следовательно, для защиты от CSRF-атак необходимо только проверять значение Referer для каждого запроса на удаление публикации.www.c.comЕсли доменное имя начинается с имени домена, это означает, что запрос исходит от самого веб-сайта и является законным. Если Referer является другим веб-сайтом, это может быть атака CSRF, и запрос может быть отклонен.

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

if (req.headers.referer !== 'http://www.c.com:8002/') {
    res.write('csrf 攻击');
    return;
}

Referer Check может не только предотвратить CSRF-атаки, но и еще один сценарий применения — «предотвращение хотлинкинга изображений».

Добавить проверку токена

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

Суммировать

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

Защита от XSS-атак
- HttpOnly предотвращает захват файлов cookie
- Проверка пользовательского ввода
- Проверка вывода на стороне сервера
Защита от CSRF-атак
- проверяющий код
- Referer Check
- Проверка токена

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

Cross-site scripting
Ответ на CSRF-атаки
«Белая шляпа говорит о веб-безопасности»