Я изучаю способы обеспечения приложения javascript, над которым я работаю. Приложение является чат-клиентом, который использует APE (Ajax Push Engine) в качестве бэкэнд.
В настоящее время каждый может получить доступ к странице и выполнить запрос GET / POST на сервер APE. Я хочу только обслуживать чат-клиент для зарегистрированных пользователей, и я хочу, чтобы их запросы были приняты только. Я могу использовать аутентификацию имени пользователя и пароля с помощью PHP для обслуживания страницы пользователя. Но как только у них появится страница, что мешает им модифицировать javascript или позволить ему попасть в чужие руки?
Этот метод защиты клиент-серверного приложения выглядит многообещающим: http://abhinavsingh.com/blog/2009/12/how-to-add-content-verification-using-hmac-in-php/
У меня есть еще один источник, который говорит, что это идеально подходит для javascript-клиента, поскольку он не зависит от отправки закрытого ключа. Но как это может быть? Согласно вышеприведенному руководству, клиент должен предоставить секретный ключ. Это не кажется очень безопасным, поскольку любой, у кого есть javascript, теперь есть закрытый ключ этого пользователя. Насколько я понимаю, это сработает примерно так:
Как это безопасно, если приложение javascript должно знать секретный ключ?
Спасибо за помощь!
Аутентификация HMAC лучше обслуживается для API, к которому будут подключаться третьи стороны. Похоже, ваше приложение будет лучше обслуживаться, написав файл cookie в браузере клиента, указав, что они прошли проверку подлинности. Затем с каждым запросом ajax вы можете проверить этот файл cookie.
Редактирование: я немного вернусь к тому, что я сказал о том, что HMAC лучше обслуживается сторонними API. Традиционно с HMAC каждый пользователь получает свой собственный секретный ключ. Я не думаю, что это необходимо для вашего приложения. Возможно, вам удастся просто сохранить один главный секретный ключ и дать каждому пользователю уникальный «общедоступный» ключ (я называю его открытым ключом, но на самом деле пользователь никогда не узнает о ключе). Когда пользователь войдет в систему, я напишу два файла cookie. Один из них представляет собой комбинацию открытого ключа пользователя + штамп времени, зашифрованный, и другой ключ, указывающий, что такое метка времени. Затем на стороне сервера вы можете проверить зашифрованный ключ и проверить, что отметка времени находится в пределах заданного порога (скажем, 10-30 минут, если они сидят без дела в вашем приложении). Если они проверены, обновите зашифрованный ключ и отметку времени, ополосните и повторите.
Ответ. Технически вы не можете запретить пользователю изменять JavaScript . Поэтому не беспокойтесь об этом, потому что вы ничего не можете с этим поделать.
Тем не менее, атака, которую вам нужно предотвратить, – это подделка запросов на межсайтовый запрос (CSRF). Вредоносные скрипты в разных доменах могут автоматически отправлять формы в ваш домен с помощью файлов cookie, хранящихся в браузере. Чтобы справиться с этим, вам необходимо включить токен аутентификации (который должен быть достаточно случайным, не связанным с именем пользователя или паролем и отправленным на странице HTML, в которой находится клиент чата) в фактических данных, отправленных по запросу AJAX ( который автоматически не заполняется браузером).
Как это безопасно, если приложение javascript должно знать секретный ключ?
Почему нет? Это собственный личный ключ пользователя, поэтому, если он хочет передать его кому-то другому, это его проблема. Это ничем не отличается от выдачи пароля, а затем говорит, что кто-то еще имеет доступ к вашей учетной записи.
Если вы немного подумаете об этом, вы поймете, что вам не нужно реализовывать шифрование с открытым ключом, HMAC или что-то в этом роде. Ваша обычная аутентификация на основе сеанса будет выполняться, если сам канал связи защищен (скажем, с помощью HTTPS).