Comments 22
При использовании HTTPS URL шифруется.
- Для безопасного использования схем аутентификации должен использоваться протокол, который обеспечивает шифрование данных и HTTP заголовков, например HTTPS.
- Нельзя посылать аутентификационные данные (логин/пароль или токен) в URL, т.к. URL не шифруется
+2
Спасибо за уточнение, поправил, действительно, при использовании HTTPS шифруется весь HTTP запрос, включая URL и параметры, а не шифруется только IP адрес и порт, т.к. это нужно для маршрутизации.
+1
Все равно совет про то, что не следует посылать чувствительные данные в URL, был здравым.
Навскидку две проблемы могу вспомнить, но, мне кажется, их больше:
— (редкая проблема) если пароль/токен попал в URL, то пользователь может добавить этот URL в закладки, скопировать его куда-то, URL попадет в историю, и т.д. Такая проблема была актуальна, когда юзали в основном html submit формы, а не SPA;
— (более актуальная проблема) многие сервере и reverse proxy логируют урлы целиком со всеми параметрами. А попадание незашифрованных credentials в логи — это, однозначно, bad practice.
Навскидку две проблемы могу вспомнить, но, мне кажется, их больше:
— (редкая проблема) если пароль/токен попал в URL, то пользователь может добавить этот URL в закладки, скопировать его куда-то, URL попадет в историю, и т.д. Такая проблема была актуальна, когда юзали в основном html submit формы, а не SPA;
— (более актуальная проблема) многие сервере и reverse proxy логируют урлы целиком со всеми параметрами. А попадание незашифрованных credentials в логи — это, однозначно, bad practice.
+5
Согласен и OWASP об этом явно говорит в разделе: Sensitive information in HTTP requests
Добавил пункт в список: «API7:2019 Security Misconfiguration»
Добавил пункт в список: «API7:2019 Security Misconfiguration»
0
многие сервере и reverse proxy логируют урлы целиком со всеми параметрами.
И им ничто не мешает логировать любые заголовки.
0
UFO just landed and posted this here
Если придираться, то HTTPS использует не SSL, а TLS протокол. Но вы, конечно, правы URL шифруется полностью, а IP:Port мы видим в открытом виде, т.к. они используются на другом уровне сетевого стека.
0
Модель OSI тут не при чём. Модель на то и модель, что это абстракция для разработчика/пользователя — последовательность обработки данных внутри ОС. Для примера, VLAN как бы вносит дополнительный уровень, но ничего никуда не заворачивается, это просто поле данных в том же самом Ethernet-фрэйме.
0
Спасибо! Очень полезная инфа. С удовольствием бы апвоутнул, но за 5 лет чтения хабра не накопил кармы :)
-2
API1:2019 Broken Object Level Authorization
— Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.
Подскажите, пожалуйста, какие есть способы реализовать это? Дело в том, что мы это реализовываем в своих проектах через т.н. реализацию МРД (модели разграничения доступа, но, возможно, это наш внутренний термин).
МРД — это документ в котором мы прописываем для каждого объекта правила доступа нему со стороны каждого субъекта. Потом эту МРД реализуем в коде на Java. Но получается жутко сложно, много ошибок и косяков.
Может есть какая-то книжка или бест-практика как это реализовывать проще?
+1
модели разграничения доступа бывают разные.
Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)
более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.
Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)
более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам
Access Control List (ACL) — это когда ручками прописывается кто имеет доступ и на что (см. файловая система в *nix)
более эффективной практикой считается разграничение по ролям RBAC — но тут надо предусмотреть разделение обязанности на разные роли (segregation of duties), например чтобы создавая запись об объекте, он не имел дальнейшего доступа к его функциям, чтобы потенциально не смог злоупотребить.
Например если админ создал учетку юзера, то он не знает пароль к учетке и не может под ней залогиниться. Только отправить ссылку со сбросом пароля на почту юзеру. Также не может удалить запись аудита своих действий (логи о создании учетки и сбросе пароля например)
более продвинутым является ABAC — это расширение RBAC, только используются любые атрибуты, а не только роли. Если вам надоело создавать список ролей и поддерживать отношения субъект->роли и объект->роль->доступ то можете заменить «роль» на аттрибуты и это больше похоже станет на разграничение доступа по бизнес-правилам
+1
OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:
- Role-Based Access Control (RBAC)
- Discretionary Access Control (DAC)
- Mandatory Access Control (MAC)
- Permission Based Access Control
0
Спасибо. очень полезно. Вечный вопрос — где хранить Bearer токен в случае с Single Page Applications? В cookies, local store, session store или переменной? Недавно читал что все же рекомендуют в cookies, потому что CSRF атаку легче предотвратить фильтруя в какие запросы вставлять cookies, а все остальные методы подвержены XSS, которая и чаще встречается и легче эксплуатируется. Что думаете?
+1
ИМХО главное чтобы при генерации нового bearer token генерировался и новый refresh token (и чтобы они протухали быстро. Помнится с амазоновскими токенами мне понравилась их гибридная схема «первый токен протухает за 5 минут, остальные — через час»)
А почему сомнения в cookies? Насколько я понимаю- HttpOnly именно для этого и был сделан.
А почему сомнения в cookies? Насколько я понимаю- HttpOnly именно для этого и был сделан.
+1
Да, насчет времени актуальности токена согласен. Ну а если ставить HttpOnly, то для SPA приложения не будет доступна дополнительная информациях из токена (например о пользователе, уровне доступа и прочее). Тут как вариант можно делать дополнительный запрос чтобы получить нужную инфу или можно разделить токен, инфу хранить в доступной для JS части, а подпись в cookies.
0
а что мешает сделать это одним запросом? Можно же установить несколько кук — в одной токен+HttpOnly, в остальных — нужная инфа
0
OWASP склоняется к cookies с реализацией дополнительных механизмов безопасности:
JSON Web Token Cheat Sheet for Java
JSON Web Token Cheat Sheet for Java
0
Только сейчас наткнулся на статью. Огромное спасибо за её написание!
+1
Sign up to leave a comment.
Безопасность REST API от А до ПИ