Arhn - архитектура программирования

Достаточно ли использования только HTTPS для защиты веб-приложения API RESTful?

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

После установления HTTPS-сессии и первоначального входа в систему нет необходимости в передаче токенов, файлов cookie, HMAC, одноразовых номеров и т. д. Базовая аутентификация или HMAC, OAuth и т. д. также не имеют значения: сеанс HTTPS безопасен.

Я, наверное, что-то упускаю. Вот как я представляю, как работает мое решение: -

  1. Пользователь переходит на страницу входа в веб-приложение (HTTPS://acme.com/login)
  2. Пользователь указывает имя пользователя и пароль
  3. Веб-сервис проверяет имя пользователя и пароль: разрешает доступ к авторизованным ресурсам

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

  1. передать имя пользователя в виде открытого текста в качестве заголовка или файла cookie - это RESTful, IMO
  2. используйте идентификатор сеанса SSL (если он доступен для фреймворка) для поиска пользователя. Это не совсем RESTful, так как идентификатор сеанса необходимо хранить

Я не вижу причин использовать что-то еще, кроме HTTPS. Что я упускаю, какие уязвимости или недостающий функционал?

Спасибо!

rest restful-authentication restful-architecture
26.03.2014

Ответы:


1

Базовая аутентификация HTTP (т. е. имя пользователя и пароль) + HTTPS обычно считается достаточно безопасным для большинства API REST, особенно для внутреннего использования. Однако без уникального одноразового номера (или идентификатора транзакции) вы уязвимы для повторных атак.

Например, представьте, что злоумышленник смог записать подлинный запрос PUT, чтобы создать новую запись в вашей базе данных. Затем они могут воспроизвести это сообщение в цикле, чтобы запустить DoS-атаку на ваш API, заполнив таблицы вашей базы данных. Хотя сообщение было зашифровано с помощью SSL, оно по-прежнему содержит действительные учетные данные, поэтому каждый повторный запрос от злоумышленника будет должным образом расшифрован и успешно аутентифицирован вашим API.

Дайджест-аутентификация HTTP включает одноразовый номер, который меняется для каждого запроса, и поэтому считается более безопасным вариантом.

15.05.2014
  • +1 за повторную атаку и преодоление через Digest Auth. 15.05.2014
  • Я думаю, что HTTPS на самом деле защищает от повторной атаки. См. serverfault.com/questions/32473/ и security.stackexchange.com/questions/20105/ 14.06.2014
  • @ Даниэль Да, ты прав - обычно. Однако я отмечаю, что комментарии к этим ответам оставляют некоторые сомнения. Я пришел к выводу, что стандарт HTTPS должен предотвращать атаки повторного воспроизведения, но некоторые реализации этого стандарта могут этого не делать. 19.06.2014

    • 2

    Вы должны определить безопасность здесь. SSL довольно безопасен (несмотря на недавние проблемы с OpenSSL/Heartbleed).

    Однако, как я вижу, вы используете имя пользователя и пароль/логин, почему бы не объединить HTTP Basic и HTTPS? Большинство фреймворков поддерживают базовую аутентификацию, поэтому. Просто аутентифицируйте пользователя каждый раз, когда вы звоните. Это единственный способ быть RESTFul с аутентификацией, так как вы хотите быть без гражданства.

    13.05.2014
  • Я усовершенствовал свою архитектуру и теперь думаю о том, чтобы сделать мое приложение управляемым сервером с прогрессивным улучшением на стороне клиента (браузера). Он по-прежнему будет RESTful, поэтому его можно будет использовать с другими типами клиентов (представления JSON/XML/HTML). Но как мне выйти из системы с помощью базовой или дайджест-аутентификации? Я могу легко сделать это с помощью пользовательского клиента, но как через браузер? 15.05.2014
  • Я предполагаю, что вы можете удалить заголовок Auth для основного. Я не знаком с Дайджестом на 100%, кроме основной предпосылки. 20.05.2014
    • Новые материалы
    Коллекции публикаций по глубокому обучению
    Последние пару месяцев я создавал коллекции последних академических публикаций по различным подполям глубокого обучения в моем блоге https://amundtveit.com - эта публикация дает обзор 25..
    Представляем: Pepita
    Фреймворк JavaScript с открытым исходным кодом Я знаю, что недостатка в фреймворках JavaScript нет. Но я просто не мог остановиться. Я хотел написать что-то сам, со своими собственными..
    Советы по коду Laravel #2
    1-) Найти // You can specify the columns you need // in when you use the find method on a model User::find(‘id’, [‘email’,’name’]); // You can increment or decrement // a field in..
    Работа с временными рядами спутниковых изображений, часть 3 (аналитика данных)
    Анализ временных рядов спутниковых изображений для данных наблюдений за большой Землей (arXiv) Автор: Рольф Симоэс , Жильберто Камара , Жильберто Кейрос , Фелипе Соуза , Педро Р. Андраде ,..
    3 способа решить квадратное уравнение (3-й мой любимый) -
    1. Методом факторизации — 2. Используя квадратичную формулу — 3. Заполнив квадрат — Давайте поймем это, решив это простое уравнение: Мы пытаемся сделать LHS,..
    Создание VR-миров с A-Frame
    Виртуальная реальность (и дополненная реальность) стали главными модными терминами в образовательных технологиях. С недорогими VR-гарнитурами, такими как Google Cardboard , и использованием..
    Демистификация рекурсии
    КОДЕКС Демистификация рекурсии Упрощенная концепция ошеломляющей О чем весь этот шум? Рекурсия, кажется, единственная тема, от которой у каждого начинающего студента-информатика..