Безопасность схем аутентификации REST

https://stackoverflow.com/questions/454355

19-08-2019
|

Вопрос

Предыстория:

Я разрабатываю схему аутентификации для веб-службы REST.Это "на самом деле" не обязательно должно быть безопасным (это скорее личный проект), но я хочу сделать его максимально безопасным в качестве упражнения / обучения.Я не хочу использовать SSL, так как мне не нужны хлопоты и, в основном, расходы на его настройку.

Эти вопросы SO были особенно полезны для начала работы:

Я подумываю об использовании упрощенной версии Аутентификация Amazon S3 (Мне нравится OAuth ( ОАВТ ) но это кажется слишком сложным для моих нужд).Я добавляю случайно сгенерированный одноразовый, предоставляемый сервером на запрос, для предотвращения повторных атак.

Чтобы перейти к вопросу:

И S3, и OAuth полагаются на подпись URL-адреса запроса вместе с несколькими выбранными заголовками. Ни один из них не подписывает текст запроса для запросов POST или PUT.Разве это не уязвимо для атаки типа "человек посередине", которая сохраняет URL-адрес и заголовки и заменяет тело запроса любыми данными, которые нужны злоумышленнику?

Похоже, я могу защититься от этого, включив хэш тела запроса в строку, которая подписывается.Безопасно ли это?

Решение

Предыдущий ответ упоминал SSL только в контексте передачи данных и фактически не касался аутентификации.

Вы действительно спрашиваете о безопасной аутентификации клиентов REST API.Если вы не используете проверку подлинности клиента TLS, SSL один не является жизнеспособным механизмом аутентификации для REST API.SSL без авторизации клиента аутентифицирует только сервер, что не имеет значения для большинства REST API , потому что вы действительно хотите аутентифицировать клиент.

Если вы не используете аутентификацию клиента TLS, вам нужно будет использовать что-то вроде схемы аутентификации на основе дайджеста (например, пользовательскую схему Amazon Web Service) или OAuth 1.0a или даже базовую аутентификацию HTTP (но только через SSL).

Эти схемы подтверждают, что запрос был отправлен кем-то ожидаемым.TLS (SSL) (без аутентификации клиента) гарантирует, что данные, передаваемые по проводу, остаются нетронутыми.Это отдельные, но дополняющие друг друга проблемы.

Для тех, кому интересно, я расширил вопрос SO о Схемы аутентификации HTTP и как они работают.

Другие советы

REST означает работу со стандартами Интернета, а стандартом для "безопасной" передачи данных в Интернете является SSL.Все остальное будет довольно сложным и потребует дополнительных усилий по развертыванию для клиентов, которым должны быть доступны библиотеки шифрования.

Как только вы переходите на SSL, для аутентификации в принципе не требуется ничего особенного.Вы снова можете использовать веб-стандарты и использовать HTTP Basic auth (имя пользователя и секретный токен, отправляемые вместе с каждым запросом), поскольку это намного проще, чем сложный протокол подписи, и все еще эффективно в контексте безопасного соединения.Вам просто нужно быть уверенным, что пароль никогда не передается обычным текстом;таким образом, если пароль когда-либо будет получен по обычному текстовому соединению, вы можете даже отключить пароль и отправить разработчику электронное письмо.Вы также должны убедиться, что учетные данные нигде не регистрируются при получении, точно так же, как вы бы не вводили обычный пароль.

HTTP Digest - это более безопасный подход, поскольку он предотвращает передачу секретного токена;вместо этого это хэш, который сервер может проверить на другом конце.Хотя это может оказаться излишеством для менее чувствительных приложений, если вы приняли меры предосторожности, упомянутые выше.В конце концов, пароль пользователя уже передается в виде обычного текста при входе в систему (если только вы не используете какое-нибудь навороченное шифрование JavaScript в браузере), а также их файлы cookie при каждом запросе.

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

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

(Обновлено, чтобы охватить последствия перехода на соединение только по протоколу SSL.)

Или вы могли бы воспользоваться известным решением этой проблемы и использовать SSL.Самоподписанные сертификаты бесплатны, и это личный проект, не так ли?

Если вам требуется хэш тела в качестве одного из параметров в URL-адресе, и этот URL-адрес подписан с помощью закрытого ключа, то атака "человек посередине" сможет заменить тело только содержимым, которое сгенерирует тот же хэш.По крайней мере, теперь это легко сделать с хэш-значениями MD5, а когда SHA-1 сломан, что ж, вы получаете картину.

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

Фактически, оригинальный S3 auth делает разрешить подпись содержимого, хотя и со слабой подписью MD5.Вы можете просто применить их необязательную практику включения заголовка Content-MD5 в HMAC (строка, подлежащая подписи).

http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html

Их новая схема аутентификации v4 более безопасна.

http://docs.aws.amazon.com/general/latest/gr/signature-version-4.html

Помните, что ваши предложения затрудняют клиентам взаимодействие с сервером.Они должны понять ваше инновационное решение и соответственно зашифровать данные, эта модель не очень хороша для общедоступного API (если только вы не amazon \ yahoo \ google ..).

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

XML-шифрование (стандарт W3C)

Безопасность XML

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow