Блог

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

смотрите 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)