Вход в Ajax и файлы cookie JavaScript, это безопасно?

Question

Я делаю систему входа в систему Ajax, и мне интересно, насколько это безопасно

1. Разместите имя пользователя и пароль с помощью ajax
2. Проверьте сервер входа в систему, если он действителен, верните новый идентификатор сеанса и идентификатор пользователя в строке JSON
3. Получите JSON с javascript, затем создайте куки сессии "session_id" и "user_id"
4. Вызовите страницу, на которой зарегистрированный пользователь перенаправляется с помощью AJAX

Спасибо

Answer 1

Создание системы безопасного входа в систему HARD . Я просто хотел бы назвать несколько вещей, которые могут пойти не так (укусить вас за задницу):

• незащищенное соединение (http вместо https).
• XSS
• CSRF
• SQL-инъекция
• незашифрованные пароли или простой md5, уязвимый для атаки радужной таблицы.

Существует множество бесплатных систем безопасного входа (созданных экспертами по безопасности), которые вы должны использовать вместо этого, например:

• Facebook Connect
• google friend connect
• щебетать единый знак
• 1026 * Вконтакте *

Answer 2

Безопасность для веб-сайта 08/15: да
Безопасность для онлайн-банкинга: нет

Используемый вами метод эквивалентен незашифрованному ежедневному входу в систему .Хотя вы не должны полагаться на куки "user_id".Вместо этого сохраните проверенный user_id только в хранилище сеансов.

Также вы можете попытаться просто вернуть cookie сеанса в результате JSON для вызова AJAX.Обычно он придерживается всех дальнейших HTTP-запросов, поэтому вам не нужно (3) дополнительно устанавливать cookie с помощью Javascript.

Answer 3

Я могу думать о нескольких проблемах с этой идеей, в прямом порядке важности (наименее для большинства):

1) Ваш сайт не будет работать для тех, у кого отключен JS.

2) Ваш сайт может не отображать желтую панель инструментов в браузере, чтобы уведомить пользователя о том, что SSL / HTTPS включен. (Зависит от реализации).

3) Параметр user_id не является обязательным для клиентской стороны и, вероятно, также не является хорошей идеей. Токены аутентификации почти всегда являются одним идентификатором, и это все, что требуется для подтверждения того, что пользователь вошел в систему.

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

Answer 4

Я думаю, что это может быть безопасно при использовании сообщения в шаге 1. уже зашифрованный пароль и немного зашифрованное имя пользователя, чтобы избежать простых атак.
Как send(base64_encode(username),md5(password));

И еще одно слово, вы должны проверитьдопустимый идентификатор сеанса на стороне сервера, а не на стороне клиента в приложении.
Вы не можете позволить клиентскому сценарию (который может быть изменен пользователем с правами доступа) проверять действительность сеанса.

Это похоже на созданиекрасивый и безопасный API, вы должны проверять все на сервере и не допускать, чтобы опасные (установка / удаление / создание методов и т. д.) были открыты по всему миру.