Защита клиента javascript с помощью hmac - PullRequest
Новая
       4

Защита клиента javascript с помощью hmac

9 голосов
/ 23 ноября 2010

Я исследую способы защиты приложения на 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, теперь есть закрытый ключ этого пользователя. Из того, что я понимаю, это будет работать примерно так:

  1. Пользователь входит в систему с именем пользователя и паролем
  2. PHP проверяет имя пользователя и пароль, ищет закрытый ключ пользователя и вставляет его в JavaScript
  3. Javascript предоставляет подпись (используя закрытый ключ) и открытый ключ со всеми запросами APE
  4. APE сравнивает вычисленную подпись с полученной подписью и решает, обрабатывать ли запросы.

Насколько это безопасно, если приложению javascript необходимо знать о закрытом ключе?

Спасибо за помощь!

Ответы [ 3 ]

2 голосов
/ 23 ноября 2010

Ответ: Технически не может помешать пользователю изменить JavaScript . Так что не беспокойтесь об этом, потому что вы ничего не можете с этим поделать.

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

1 голос
/ 23 ноября 2010

Насколько это безопасно, если приложению javascript необходимо знать о закрытом ключе?

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

Если вы немного подумаете об этом, вы поймете, что вам не нужно реализовывать шифрование с открытым ключом, HMAC или что-то подобное. Ваша обычная сеансовая аутентификация подойдет, если сам канал связи защищен (скажем, с использованием HTTPS).

0 голосов
/ 23 ноября 2010

Аутентификация HMAC лучше обслуживать для API, к которому будут подключаться третьи стороны.Похоже, что ваше приложение будет лучше обслуживаться, если в браузере клиента будет сохранен файл cookie, указывающий, что они прошли проверку подлинности.Затем с каждым запросом ajax вы можете проверить наличие этого cookie.

Редактировать: Я возвращаюсь к тому, что я сказал о том, что HMAC лучше обслуживается сторонними API.Традиционно с HMAC каждый пользователь получает свой собственный закрытый ключ.Я не думаю, что это необходимо для вашего приложения.Возможно, вам не удастся просто сохранить один главный закрытый ключ и дать каждому пользователю уникальный «открытый» ключ (я называю его открытым ключом, но на самом деле пользователь никогда не узнает о ключе).Когда пользователь входит в систему, я бы написал два куки.Один, который представляет собой комбинацию открытого ключа пользователя + зашифрованной метки времени, и другой ключ, указывающий, что такое метка времени.Затем на стороне сервера вы можете проверить зашифрованный ключ и проверить, что отметка времени находится в пределах заданного порога (скажем, 10-30 минут, если они бездействуют в вашем приложении).Если они проверены, обновите зашифрованный ключ и отметку времени, промойте и повторите.

...