Безопасность REST API от А до ПИ

[KYuri]

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

При использовании HTTPS URL шифруется.

[AlexeySushkov]

Спасибо за уточнение, поправил, действительно, при использовании HTTPS шифруется весь HTTP запрос, включая URL и параметры, а не шифруется только IP адрес и порт, т.к. это нужно для маршрутизации.

[Perlovich]

Все равно совет про то, что не следует посылать чувствительные данные в URL, был здравым.

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

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

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

[AlexeySushkov]

Согласен и OWASP об этом явно говорит в разделе: Sensitive information in HTTP requests
Добавил пункт в список: «API7:2019 Security Misconfiguration»

[savostin]

многие сервере и reverse proxy логируют урлы целиком со всеми параметрами.

И им ничто не мешает логировать любые заголовки.

[AlexeySushkov]

Если будет https, то заголовки будут зашифрованными

[savostin]

Тогда и URL тоже. Это ж просто другая строка в запросе ;)

[AlexeySushkov]

Если придираться, то HTTPS использует не SSL, а TLS протокол. Но вы, конечно, правы URL шифруется полностью, а IP:Port мы видим в открытом виде, т.к. они используются на другом уровне сетевого стека.

[Busla]

Модель OSI тут не при чём. Модель на то и модель, что это абстракция для разработчика/пользователя — последовательность обработки данных внутри ОС. Для примера, VLAN как бы вносит дополнительный уровень, но ничего никуда не заворачивается, это просто поле данных в том же самом Ethernet-фрэйме.

[hbrmdc]

Спасибо! Очень полезная инфа. С удовольствием бы апвоутнул, но за 5 лет чтения хабра не накопил кармы :)

[Savochkin]

API1:2019 Broken Object Level Authorization
— Проверять, что залогиненный пользователь имеет доступ только к разрешенным объектам.

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

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

Может есть какая-то книжка или бест-практика как это реализовывать проще?

[somurzakov]

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

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

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

[AlexeySushkov]

OWASP рекомендует (Access Control Cheat Sheet) следующие модели обеспечения контроля доступа:

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

[4ourth]

Спасибо. очень полезно. Вечный вопрос — где хранить Bearer токен в случае с Single Page Applications? В cookies, local store, session store или переменной? Недавно читал что все же рекомендуют в cookies, потому что CSRF атаку легче предотвратить фильтруя в какие запросы вставлять cookies, а все остальные методы подвержены XSS, которая и чаще встречается и легче эксплуатируется. Что думаете?

[vassabi]

ИМХО главное чтобы при генерации нового bearer token генерировался и новый refresh token (и чтобы они протухали быстро. Помнится с амазоновскими токенами мне понравилась их гибридная схема «первый токен протухает за 5 минут, остальные — через час»)
А почему сомнения в cookies? Насколько я понимаю- HttpOnly именно для этого и был сделан.

[4ourth]

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

[vassabi]

а что мешает сделать это одним запросом? Можно же установить несколько кук — в одной токен+HttpOnly, в остальных — нужная инфа

[4ourth]

Просто думал о том, что бы не хранить избыточные данные, но вариант работающий, Вы правы.

[AlexeySushkov]

OWASP склоняется к cookies с реализацией дополнительных механизмов безопасности:
JSON Web Token Cheat Sheet for Java

[4ourth]

Да, спасибо, почитаю:)

[batr]

Только сейчас наткнулся на статью. Огромное спасибо за её написание!