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

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

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

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

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

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

Что я должен делать?

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

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

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

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


person crucible    schedule 10.06.2011    source источник
comment
Я бы проголосовал за №2.   -  person AC2MO    schedule 10.06.2011
comment
Мой голос также будет под номером 2, если у токена также истек срок действия.   -  person James Khoury    schedule 14.06.2011


Ответы (5)


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

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

Тем не менее, вам следует учесть несколько моментов:

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

  2. Хранилище DOM может быть немного сложнее, чем файлы cookie.

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

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

person Community    schedule 14.06.2011
comment
Безусловно, будут ограничения и проверки того, что каждый пользователь может делать на стороне сервера, и ведение журнала, но я хотел убедиться, что то, что сообщает серверу, кто этот человек, не подвержено повреждению. - person crucible; 14.06.2011

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

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

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

person LewisBenge    schedule 13.06.2011

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

person Justin Schwartzenberger    schedule 13.06.2011
comment
Мне все еще нужно предоставить способ узнать, кто этот человек, и подтвердить это, для чего, вероятно, по-прежнему потребуется токен? - person crucible; 14.06.2011
comment
@ justin-schwartzenberger А что насчет всех остальных, кто может получить доступ к моему коду на стороне сервера? Технически они получают доступ к защищенным ресурсам бесплатно, если я не защищу свою серверную часть, чтобы она выполнялась только из того же домена. - person Preslav Rachev; 19.12.2013

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

person John Sheehan    schedule 13.06.2011

см. 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)

person Thinker    schedule 10.06.2011
comment
Это говорит мне, как использовать / реализовать ключ API, но не отвечает на вопрос о его защите. - person crucible; 10.06.2011