Лучший способ обезопасить приложение AJAX - PullRequest
13 голосов
/ 23 сентября 2008

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

Мой первоначальный подход - система на основе файлов cookie. По сути, я установил cookie с кодом авторизации, и каждый доступ к данным менял cookie. Кроме того, всякий раз, когда происходила неудачная аутентификация, все сеансы этого пользователя де-аутентифицировались, чтобы не допустить угонщиков. Чтобы перехватить сеанс, кому-то придется оставить себя в системе, а хакеру нужно отправить самое последнее обновление cookie, чтобы подделать сеанс.

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

Мои идеи были:

  • Определенно менее безопасный метод, основанный на сеансах
  • использование SSL для всего сайта (кажется, что это слишком много)
  • Использование iFrame, который ssl-аутентифицирован, для выполнения безопасных транзакций (я просто уверен, что это возможно, с небольшим количеством взлома jquery)

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

Определенно менее безопасный метод на основе сеанса

Ответы [ 6 ]

1 голос
/ 30 сентября 2008

Распространенным решением является хеширование идентификатора сеанса пользователя и передача его при каждом запросе, чтобы убедиться, что запрос поступил от действительного пользователя (см. это слайд-шоу ). Это достаточно безопасно с точки зрения CSRF , но если кто-то перехватывает данные, они могут быть перехвачены. В зависимости от ваших потребностей, ssl всегда будет самым безопасным методом.

1 голос
/ 24 сентября 2008

SSL является обязательным, предотвращая прозрачные прокси-соединения, которые могут быть использованы несколькими пользователями. Тогда я бы просто проверил входящий IP-адрес с тем, который был аутентифицирован.

Re-Authenticate:

  • как только IP-адрес изменится
  • на тайм-аут больше n секунд без запроса
  • индивидуально по любой важной транзакции
1 голос
/ 23 сентября 2008

Лично я не нашел использование SSL для всего сайта (или большей его части) излишним. Может быть, некоторое время назад, когда скорость и скорость были ниже. Теперь я без колебаний поместил бы любую часть сайта под SSL.

Если вы решили, что использование SSL для всего сайта приемлемо, вы можете рассмотреть возможность использования старой «Базовой аутентификации», когда сервер возвращает ответ 401 , в результате чего браузер запрашивает имя пользователя / пароль. Если ваше приложение может работать с этим типом входа в систему, это прекрасно работает для AJAX и всех других обращений к вашему сайту, потому что браузер обрабатывает повторную отправку запросов с соответствующими учетными данными (и это безопасно, если вы используете SSL, но только если вы используете SSL - не используйте Basic auth с обычным http!).

0 голосов
/ 30 сентября 2008

Вы можете попробовать прочесть книгу «Безопасность Ajax» Билли Хоффмана и Брайана Салливана. Я обнаружил, что это изменило мой взгляд на безопасность. Для каждой фазы Ajax есть очень конкретные предложения.

0 голосов
/ 23 сентября 2008

Лучше всего использовать SSL-соединение по ранее аутентифицированному соединению с чем-то Apache и / или Tomcat. Аутентификация на основе форм в любом из них с обязательным SSL-соединением дает вам безопасное соединение. Затем веб-приложение может обеспечить безопасность и идентификацию для сеанса, и Ajax на стороне клиента не нужно беспокоиться о безопасности.

0 голосов
/ 23 сентября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...