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

Question

Справочная информация:

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

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

• Аутентификация RESTful
• Рекомендации по защите REST API / веб-службы
• Примеры лучших веб-API SOAP / REST / RPC? И почему они тебе нравятся? А что с ними не так?

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

Фактически, исходная аутентификация S3 позволяет разрешать подписывать содержимое, хотя и со слабой подписью 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

Answer 6

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

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

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

XML Security