Защита запросов AJAX через GUID

Question

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

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

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

EDIT:

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

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

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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