Comments 18
  • Для безопасного использования схем аутентификации должен использоваться протокол, который обеспечивает шифрование данных и HTTP заголовков, например HTTPS.
  • Нельзя посылать аутентификационные данные (логин/пароль или токен) в URL, т.к. URL не шифруется
При использовании HTTPS URL шифруется.
Спасибо за уточнение, поправил, действительно, при использовании HTTPS шифруется весь HTTP запрос, включая URL и параметры, а не шифруется только IP адрес и порт, т.к. это нужно для маршрутизации.
Все равно совет про то, что не следует посылать чувствительные данные в URL, был здравым.

Навскидку две проблемы могу вспомнить, но, мне кажется, их больше:

— (редкая проблема) если пароль/токен попал в URL, то пользователь может добавить этот URL в закладки, скопировать его куда-то, URL попадет в историю, и т.д. Такая проблема была актуальна, когда юзали в основном html submit формы, а не SPA;

— (более актуальная проблема) многие сервере и reverse proxy логируют урлы целиком со всеми параметрами. А попадание незашифрованных credentials в логи — это, однозначно, bad practice.
Почитайте про модель OSI. Выглядит так, будто вы представляете это как набор полей, а HTTPS типо выбирает какие поля шифровать, а какие нет.

Но на самом деле это даже близко не так, просто SSL находится на уровне между HTTP и TCP. И шифруется абсолютно все, что находится выше него, потому что нижние протоколы, как будто бы «заворачивают/упаковывают» вышестоящие. Поэтому весь трафик HTTP шифруется, потому что SSL шифрует все, что находится на более высоком уровне и ему все равно, HTTP это или нет. Тут еще конечно сбивает с толку, что HTTPS это на самом деле два протокола, а не один, SSL + HTTP.
Если придираться, то HTTPS использует не SSL, а TLS протокол. Но вы, конечно, правы URL шифруется полностью, а IP:Port мы видим в открытом виде, т.к. они используются на другом уровне сетевого стека.
Модель OSI тут не при чём. Модель на то и модель, что это абстракция для разработчика/пользователя — последовательность обработки данных внутри ОС. Для примера, VLAN как бы вносит дополнительный уровень, но ничего никуда не заворачивается, это просто поле данных в том же самом Ethernet-фрэйме.
Спасибо! Очень полезная инфа. С удовольствием бы апвоутнул, но за 5 лет чтения хабра не накопил кармы :)
API1:2019 Broken Object Level Authorization
— Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.


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

МРД — это документ в котором мы прописываем для каждого объекта правила доступа нему со стороны каждого субъекта. Потом эту МРД реализуем в коде на Java. Но получается жутко сложно, много ошибок и косяков.

Может есть какая-то книжка или бест-практика как это реализовывать проще?
модели разграничения доступа бывают разные.
Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)

более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.
Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)

более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам
OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

  • Role-Based Access Control (RBAC)
  • Discretionary Access Control (DAC)
  • Mandatory Access Control (MAC)
  • Permission Based Access Control

Спасибо. очень полезно. Вечный вопрос — где хранить Bearer токен в случае с Single Page Applications? В cookies, local store, session store или переменной? Недавно читал что все же рекомендуют в cookies, потому что CSRF атаку легче предотвратить фильтруя в какие запросы вставлять cookies, а все остальные методы подвержены XSS, которая и чаще встречается и легче эксплуатируется. Что думаете?
ИМХО главное чтобы при генерации нового bearer token генерировался и новый refresh token (и чтобы они протухали быстро. Помнится с амазоновскими токенами мне понравилась их гибридная схема «первый токен протухает за 5 минут, остальные — через час»)
А почему сомнения в cookies? Насколько я понимаю- HttpOnly именно для этого и был сделан.
Да, насчет времени актуальности токена согласен. Ну а если ставить HttpOnly, то для SPA приложения не будет доступна дополнительная информациях из токена (например о пользователе, уровне доступа и прочее). Тут как вариант можно делать дополнительный запрос чтобы получить нужную инфу или можно разделить токен, инфу хранить в доступной для JS части, а подпись в cookies.
Просто думал о том, что бы не хранить избыточные данные, но вариант работающий, Вы правы.
Only those users with full accounts are able to leave comments. Log in, please.