Лучший способ защитить приложение AJAX

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

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

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

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

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

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

Реже менее безопасный метод на основе сеанса

Ответ 1

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

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

Ответ 2

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

Re-Authenticate:

как только изменяется адрес ip
в тайм-ауте, превышающем n секунд без запроса
индивидуально для любой важной транзакции

Ответ 3

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

Ответ 4

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

Ответ 5

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

Ответ 6

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