Безопасный доступ к аутентифицированному серверу REST через Backbone.js?

Question

У меня был этот REST-сервер (написанный мной), который защищен простой HTTP-аутентификацией.

Теперь я переписал приложение, используя backbone.js, и я не уверен, как пройти аутентификацию моего клиента. Если я сделаю это в JS, пользователь / пароль будет виден.

Так как мне изменить мой сервер или JS на стороне клиента, чтобы обеспечить безопасность?

Ранее я просто давал пользователю и передавал PHP для каждого запроса к REST-серверу, пожалуйста, сообщите мне, спасибо.

Answer 1

HTTP Базовая аутентификация склонна к прослушиванию и атакам типа «человек посередине».Рекомендуется использовать HTTPS.

Однако, если это не вариант, вы всегда можете отправить куки обратно клиенту и ввести имя пользователя / пароль, чтобы он не отображался в файле JS.Само собой разумеется, что пароль должен быть по крайней мере зашифрован / хеширован по соображениям безопасности.Затем на стороне сервера будет лежать ответственность за получение информации об аутентификации из cookie.

Теперь, если у вас нет никакого контроля над изменением кода на стороне сервера, у вас практически не осталось вариантовкроме хоронения учетных данных в глобальном методе ajaxSend(), который будет отправлять имя пользователя / пароль при каждом запросе AJAX.Вы можете просто поместить это в какой-нибудь другой файл .js и затруднить его поиск, но вы в значительной степени ограничены этой формой безопасности.Хотя куки не делают вашу жизнь безопаснее.(Было бы хорошо, если бы пароль был хеширован / зашифрован).

Другая вещь, которую вы могли бы сделать, это иметь немного более сложную форму безопасности: сервер должен отправлять одноразовый номер с каждым ответом -nonce будет «подписан» сервером с использованием секретного ключа сервера, и вы можете использовать его для «шифрования» имени пользователя / пароля на стороне клиента для каждого запроса.Ваш сервер должен будет постоянно расшифровывать учетные данные.Это менее подвержено влиянию человека посередине, но все же не защищено от ошибок.

HTTPS спасет вас от каждого из вышеперечисленных, если это вариант для вас.

Надеюсь, это поможет.

ОБНОВЛЕНИЕ (согласно комментарию) : Суть покоя заключается в отсутствии состояния на сервере.Т.е. нет сессий!Следовательно, вам необходимо отправить учетные данные пользователя с КАЖДЫМ запросом, который клиент делает на сервере.Если у вас есть страница входа в систему, то очень трудно быть по-настоящему спокойной, поскольку нет «ресурса», называемого именем входа.Однако вот что вы можете сделать:

1. Пользователь заходит на страницу входа в систему, вводит учетные данные и нажимает кнопку «логин»
2. Отправляет POST-запрос на сервер с этими учетными данными - вероятно, на / Login
3. Пусть сервер вернет запрошенный ресурс, для которого была необходима аутентификация, И установит cookie с действительными учетными данными для использования в следующем запросе
4. Каждый последующий запрос будет направлен на соответствующий ресурсопределенный URL с определенным действием (GET, PUT, POST, DELETE ...).Сервер должен проверить данные аутентификации из куки-файла и решить, аутентифицирован ли пользователь, и выполнить дальнейшую авторизацию для предоставления доступа, если это необходимо.

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

Answer 2

Хорошо, я поговорил со своим коллегой и выдвинул лучшую идею на данный момент:

Создайте простой контроллер на своей клиентской стороне (сайте) и назовите его RESTAPI, он будет действовать как обертка для вашего фактического сервера REST.

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

Пример: если мне нужно получить

/ сообщений / отосланных

с сервера REST, теперь вместо этого я попаду по этому URL в коллекции магистралей

сайт / restapi / сообщений / отосланных

Контроллер RESTAPI также сначала проверяет, имеет ли запрашивающий пользователь надлежащий сеанс на сайте и позволяет ли ему получать ресурс или нет.

Так что не беспокойтесь о небезопасных cookie-файлах или о том, что ваш сервер REST пропускает обычный JS или использует какой-либо другой неясный метод:)

Answer 3

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