Защита AJAX-запросов с помощью GUID

Question

Я пишу веб-приложение, которое будет отправлять запросы через AJAX, и хотел бы заблокировать эти вызовы.После небольшого исследования я рассматриваю возможность использования некоторой формы случайного токена (string), который будет передан обратно вместе с запросом (GUID?).Вот важные части моего алгоритма:

1. Назначьте токен переменной JavaScript (генерируемой на стороне сервера).
2. Кроме того, сохраните этот токен в базе данных и укажите ему действительный период времени (т. е.10 минут).
3. Если токен все еще не был использован и находится в пределах допустимого временного интервала, разрешите вызов.
4. Верните запрошенную информацию, если она действительна, в противном случае зарегистрируйте запрос и проигнорируйте его.

Имеет ли это смысл с точки зрения безопасности?Будет ли работать GUID для токена - должно ли это быть что-то другое?Есть ли хороший способ зашифровать переменные в запросе?

Редактировать:

Я понимаю, что эти AJAX-запросы не были бы по-настоящему "безопасными", но я хотел бы добавить базовую безопасность в том смысле, что я хотел бы запретить другим использовать сервис, который я намерен написать.Этот случайный жетон стал бы базовой передовой защитой от оскорбительных звонков.Данные, которые были бы запрошены (и даже отправлены для создания таких данных), вряд ли будут повторены.

Возможно, я ошибаюсь, используя GUID...как насчет случайно сгенерированной строки (токена)?

Answer 1

Если вы делаете это, чтобы доверять коду, который вы отправили в клиентский браузер, то измените направление.Вы действительно не хотите доверять пользовательскому вводу, который включает вызовы из js, отправленные вами в браузер.Логика на сервере должна быть устроена так, чтобы через нее нельзя было сделать ничего плохого.Тем не менее, asp.net использует подписанное поле, возможно, вы захотите пойти этим путем, если это абсолютно необходимо.

Немного расширяясь:Asp.net защищает viewstate от несанкционированного доступа, который отправляется в виде скрытого поля html (в зависимости от конфигурации).Я уверен, что есть ссылки получше, но, по крайней мере, это упоминается в этой статье: http://msdn.microsoft.com/en-us/library/ms998288.aspx

проверка подлинности.Это определяет хэширование алгоритм, используемый для генерации HMAC, чтобы обеспечить ViewState и forms защиту от несанкционированного доступа к билетам аутентификации.Этот атрибут также используется для указания алгоритма шифрования, используемого для шифрования ViewState.Этот атрибут поддерживает следующие параметры:

• SHA1–SHA1 используется для защиты от несанкционированного доступа ViewState и, если настроено, билет аутентификации forms.Если для атрибута проверки выбрано значение SHA1 , используется алгоритм HMACSHA1.

Ссылка на класс .net для этого алгоритма http://msdn.microsoft.com/en-us/library/system.security.cryptography.hmacsha1.hmacsha1.aspx.

Обновление 2: Для защиты от несанкционированного доступа вы хотите подписать данные (а не зашифровать их).Обратите внимание, что при использовании криптографии в целом вам действительно следует избегать использования пользовательской реализации или алгоритма.Что касается шагов, я бы придерживался:

• Назначьте токен переменной JavaScript (генерируемой на стороне сервера). Вы указываете информацию, идентифицирующую запрос, а также точную дату и время, когда он был отправлен.Подпись подтвердит, что серверное приложение выдало данные.
• При необходимости укажите двойные отправки.

Тем не менее, причина, по которой asp.net проверяет viewstate по умолчанию, заключается в том, что разработчики полагаются на информацию, поступающую туда как обрабатываемую только приложением, когда они не должны этого делать.То же самое, вероятно, относится и к вашему сценарию, не полагайтесь на этот механизм.Если вы хотите оценить, может ли кто-то что-то сделать, используйте аутентификацию + авторизацию.Если вы хотите знать, что вызов ajax отправляет только допустимые параметры, проверьте их.Не предоставляйте API на уровне детализации, отличном от того, на котором вы можете соответствующим образом авторизовать действия.Этот механизм - всего лишь дополнительная мера на случай, если что-то соскользнет, а не реальная защита.

Ps.с приведенным выше HMACSHA1 вы бы создали его экземпляр с помощью фиксированного ключа

Answer 2

Это действительно зависит от того, чего вы пытаетесь достичь с помощью безопасности.Если вы имеете в виду предотвращение несанкционированного использования конечных точек HTTP, вы мало что можете с этим поделать, поскольку пользователь будет иметь полный доступ к HTML и JavaScript, используемым для выполнения вызовов.

Если вы имеете в виду запретить кому-либо прослушивать данные в AJAX-запросах, то я бы просто использовал SSL.

GUID, используемый так, как вы предлагаете, на самом деле просто заново изобретает файл cookie с идентификатором сеанса.

Answer 3

"Обеспечение безопасности" - это довольно расплывчатый термин.Чего именно вы пытаетесь достичь?Использование GUID - это прекрасный способ предотвратить дублирование одного и того же запроса, но это все.

Если информация, передаваемая между клиентом и сервером, действительно конфиденциальна, вы должны делать это по протоколу HTTPS.Это действительно единственный ответ в том, что касается обеспечения реальной коммуникации.

Редактировать:Чтобы ответить на ваш вопрос относительно того, является ли GUID "правильным" способом - нет правильного способа сделать то, что вы предлагаете.Использование любого токена, будь то GUID или что-то ваше собственное, не будет иметь никакого эффекта, кроме предотвращения дублирования отправки одного и того же запроса.Вот и все.