CSRF уязвимости веб-безопасности

Node.js задняя часть Безопасность ThinkJS
CSRF уязвимости веб-безопасности

Что такое CSRF

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

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

Опасности CSRF

Краткое описание Уязвимость CSRF заключается в использовании уязвимости в проверке разрешений веб-сайта для отправки запросов без ведома пользователя, чтобы достичь цели «замаскировать» пользователя. Атаки злоумышленников, использующих CSRF, в основном включают следующее:

  1. Злоумышленник может заставить пользователя-жертву выполнить любую операцию по изменению состояния, разрешенную жертвой, например: обновить данные учетной записи, завершить покупку, выйти из системы или даже войти в систему.
  2. Получить личные данные пользователя
  3. Сотрудничайте с другими эксплойтами
  4. CSRF-червь

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

способ защиты

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

Проверьте поле Реферер

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

const { parse } = require('url');
module.exports = class extends think.Logic {
  indexAction() {
    const referrer = this.ctx.referrer();
    const {host: referrerHost} = parse(referrer);
    if(referrerHost !== 'xxx') {
        return this.fail('REFERRER_ERROR');
    }
  }
}

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

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

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

  1. Случайная строка: добавьте параметр случайной строки к каждой отправке, которая доставляется сервером через страницу и добавляется к параметрам отправки для каждого запроса.Сервер определяет, является ли это запрос пользователя, проверяя согласованность параметров. Поскольку злоумышленник в атаке CSRF не может заранее узнать значение случайной строки, сервер может отклонить запрос, проверив значение.
  2. JWT: На самом деле, помимо входа в сеанс, все более популярной становится проверка входа в систему с помощью токена JWT. Этот метод заключается в записи токена входа в систему на внешнем интерфейсе и реализации процесса проверки входа путем добавления заголовка аутентификации в заголовок каждый раз, когда делается запрос. Поскольку злоумышленник не может знать значение токена в атаке CSRF, атака CSRF также может быть предотвращена таким образом. Чтобы узнать, как использовать JWT в ThinkJS, обратитесь к предыдущей статье.«Практика аутентификации ThinkJS JWT». Конечно, помимо JWT существует множество способов входа с токеном, например OAuth.

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

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

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

Категории