Ключи API веб-сервисов и Ajax - защита ключа

Question

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

Сценарий таков: веб-служба (WCF Web Api), использующая ключ API для проверки и определения пользователя, а также смесь jQuery и приложения на внешних интерфейсах.

С одной стороны, трафик может быть https, поэтому он не может быть проверен, но если я использую один и тот же ключ для каждого пользователя (скажем, guid), и я использую его в обоих случаях, есть вероятность, что он может быть использован и кто-то может выдать себя за пользователя.

Если я реализую что-то похожее на OAuth, то генерируется пользователь и ключ для каждого приложения, и это может сработать - но все же для стороны jQuery мне понадобится ключ API приложения в javascript.

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

Что мне делать?

1. md5 или как-то зашифровать ключ?
2. Поместить ключ в переменную сеанса, затем при использовании ajax его извлечь?
3. Смирись, это не так уж и сложно.

Я уверен, что это, вероятно, распространенная проблема - поэтому любые указатели приветствуются.

Чтобы сделать это более понятным - это мой API, который я написал, к которому я обращаюсь, а не Google и т. Д. Поэтому я могу делать токены сессий и т. Д., Я просто пытаюсь работать лучший способ обезопасить клиентские токены / ключи, которые я бы использовал.

Я здесь слишком осторожен, но просто использую это, чтобы учиться.

Answer 1

(я предлагаю пометить этот пост "безопасность".)

Во-первых, вы должны четко понимать, от чего вы защищаете.Вы можете доверять клиенту вообще?Искусный пользователь может вставить скрипт Greasemonkey на вашу страницу и вызвать именно тот код, который ваш пользовательский интерфейс вызывает для отправки запросов.Сокрытие всего в закрытии Javascript означает, что вам нужен отладчик;это не делает атаку невозможной.Firebug может отслеживать запросы HTTPS.Также рассмотрите скомпрометированный клиент: установлен ли кейлоггер?Виртуализирована ли вся система в тайне, чтобы злоумышленник мог проверить любую часть памяти в любое время на досуге?Безопасность, когда вы так же уязвимы, как веб-приложение, действительно сложна.

Тем не менее, вот несколько вещей, которые вы должны рассмотреть:

1. Не используйте ключи на самом делено, скорее, HMAC-хэши, например, токена, который вы даете сразу после аутентификации.

2. Хранение DOM может быть немного сложнее, чем куки.

3. Посмотрите на реализацию Google OAuth 2 для примера модели безопасности.В основном вы используете токены, которые действительны только в течение ограниченного времени (и, возможно, для одного IP-адреса).Таким образом, даже если токен перехвачен или клонирован, он действителен только в течение короткого периода времени.Конечно, вы должны быть осторожны с тем, что вы делаете, когда токен заканчивается;может ли злоумышленник сделать то же, что делает ваш код, и получить новый действительный токен?

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

Answer 2

Зависит от того, как используется ключ API. Ключи API, подобные предоставленным Google, привязаны к URL-адресу сайта, с которого был отправлен запрос; Если вы попытаетесь использовать ключ на сайте с альтернативным URL-адресом, служба выдаст ошибку и, таким образом, устранит необходимость защищать ключ на стороне клиента.

Однако некоторые базовые API-интерфейсы привязаны к клиенту и могут использоваться в нескольких доменах, поэтому в этом случае я ранее пошел с практикой оборачивания этого API-интерфейса в код на стороне сервера и наложения некоторых ограничений на то, как клиент может взаимодействовать местный сервис и охрана сервиса.

Тем не менее, моя общая рекомендация заключается в том, чтобы применить ограничения к веб-API в отношении того, как можно использовать ключи, и, таким образом, устранить сложности и необходимость пытаться защитить их на клиенте.

Answer 3

Как правило, в подобных случаях вы отправляете запросы через сервер через сервер AJAX, который проверяет, разрешено ли браузеру делать запросы.Если вы хотите вызывать службу напрямую из JavaScript, то вам нужна какая-то система токенов, например JSON Web Tokens (JWT) , и вам придется решать междоменные проблемы, если служба находится где-токроме текущего домена.

Answer 4

Как насчет использования jQuery для вызова кода на стороне сервера, который обрабатывает связь с API.Если вы используете MVC, вы можете вызвать действие контроллера, которое может содержать код и ключ API, чтобы поразить ваш сервис и вернуть частичное представление (или даже JSON) в ваш UX.Если вы используете веб-формы, вы можете создать страницу aspx, которая будет осуществлять связь API в коде, а затем записывать содержимое в поток ответов для вашего UX.Тогда ваш код UX может просто содержать некоторые вызовы $ .post () или $ .load () для вашего кода на стороне сервера, и ваш ключ API и конечная точка будут защищены.

Answer 5

см. http://blogs.msdn.com/b/rjacobs/archive/2010/06/14/how-to-do-api-key-verification-for-rest-services-in-net-4.aspx для получения дополнительной информации (Как выполнить проверку ключа API для служб REST в .NET 4)