Пароль защищает службу REST?

Question

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

Служба REST будет в основном доступна с внешнего интерфейса, насыщенного Javascript, и с учетом этого я предложил две следующие альтернативы для решения этой проблемы:

1. Заставьте пользователей войти, сначала отправив учетные данные на страницу /login с POST.Страница устанавливает cookie-файл сеанса, в котором пользователь помечается как вошедший в систему, а также уровень разрешений.При каждом последующем запросе я проверяю, вошел ли пользователь в систему и уровень его прав.Когда сеанс истекает, автоматически или вручную (выйдите из системы, пользователь должен будет повторно войти в систему).

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

Есть ли еще способы решить эту проблему, и есть ли что-то еще, что меня должно беспокоить?

Answer 1

В настоящее время я разрабатываю REST API вместе с клиентом (написан на javascript ), ниже я попытаюсь объяснить методы, используемые для защиты API от несанкционированного доступа.

• Заставьте ваш REST API запрашивать заголовок Auth-Key при каждом запросе к API, кроме того, /api/authenticate.

• /api/authenticate будет принимать имя пользователя ипароль (отправляется с помощью POST) и возвращает информацию о пользователе вместе с Auth-Key.

• Этот Auth-Key генерируется случайным образом после вызова /api/authenticate и сохраняетсяв таблице бэкэнда users с конкретной записью пользователя хеш md5 удаленного ip + агента пользователя, предоставленного клиентом.

• Для каждого запроса значение Auth-Key, а указанная сумма md5 ищется в users.Если найден действительный пользователь, который был активен в течение последних N минут, ему будет предоставлен доступ, если нет: http код возврата 401.

• Сначала в клиенте RESTполучите Auth-Key, отправив сообщение /api/authenticate, затем сохраните это значение в переменной и отправляйте при каждом последующем запросе.

Answer 2

Если вы хотите остаться верным определению службы REST, тогда она должна быть без сохранения состояния и не хранить никаких данных для входа (или других специфичных для контекста) данных на сервере: http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints

Ваш второй подход будетподходит для этой модели

Answer 3

Сначала решите, от чего вы защищаетесь:

• Аутентификация? (Зная, кто запрашивает вашу услугу?)
• Авторизация? (Может ли данное лицо правильно запросить данную услугу или нет?)

Я рекомендую вам предоставить хешированные ключи для вашего сервиса. Таким образом, вы можете управлять ключевым вопросом отдельно от сервисов. Или клиентский ключ и секрет, Amazon делает это.

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

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

Вы можете разрешить клиентам выбирать уровень безопасности, предоставляя им выбор конечных точек HTTP или SSL / HTTP для подключения. Выбор клиента - это хорошо.

Answer 4

1. Заставьте пользователей войти, сначала отправив учетные данные на страницу / логин с POST. Страница устанавливает cookie сеанса, в котором пользователь отмечен как вошли в систему, а также уровень разрешений. На каждом следующем запрос, я подтверждаю, что пользователь вошел в систему и его / ее разрешение уровень. Когда сеанс истекает, автоматически или вручную (выход из системы, пользователь должен будет повторно войти в систему).

2. Временно сохраните учетные данные, хэшированные локально, и отправьте учетные данные пользователей по каждому отдельному запросу пользователя, чтобы проверить учетные данные и права доступа для каждого отдельного запроса.

Ваш первый подход не учитывает ограничение безгражданства REST. Вы не можете поддерживать клиентские сессии на стороне сервера. Это ограничение делает REST легко масштабируемым ...

Ваше второе решение подходит. Самый простой способ использовать базовую аутентификацию HTTP. Вам не нужно хешировать пароль на стороне клиента. Вам нужно зашифрованное соединение. На стороне сервера вы можете иметь кэш [username, password] -> [identity, permissions], так что это решение намного быстрее и превосходит все остальные, чем сеансы на стороне сервера.

Для сторонних (ненадежных) клиентов аутентификация является более сложной, я думаю, вам не нужна эта часть.

Answer 5

Я не эксперт по безопасности. Я использую RESTful Play! -Webframework, и они выполняют следующие действия для аутентификации пользователей.

1. Файл cookie защищен от манипуляций. Он подписан длинным секретным ключом и проверяется для каждого запроса. Просто хеширования недостаточно !
2. Рекомендуется установить уникальную информацию для идентификации пользователя в куки. Поскольку сервер должен единственный, кто манипулирует cookie, этого достаточно.
3. Не помещайте пароль в качестве учетных данных в cookie . Если кто-то прослушивает cookie-файл, может быть взломан не только сеанс, но и полная учетная запись или, что еще хуже, другие учетные записи с такими же учетными данными.

Если вы хотите защитить куки от перехвата с использованием https.