Достаточно ли OAuth2 и SSL для защиты API

Question

Я пытаюсь найти лучший способ защитить API.Я разрешаю только SSL, и я использую OAuth2 для аутентификации, но этого недостаточно.

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

Есть ли способ предотвратить это?Я видел, как люди используют HMAC-хэш параметров, используя секретный ключ, известный только клиенту и серверу, но я вижу с этим две проблемы.

1. Очень трудно (невозможно?) Предотвратитьзлонамеренный пользователь от декомпиляции вашего клиента и выяснения секретного ключа.
2. Некоторые параметры кажутся странными для хэша HMAC.Например, если параметр был байтами файла, включаете ли вы все это в свой хэш HMAC?

Answer 1

Вы можете установить SSL с взаимной аутентификацией между вашими законными клиентами и вашим API. Создайте самозаверяющий сертификат клиента SSL и сохраните его в своем клиенте. Настройте сервер так, чтобы он требовал аутентификации на стороне клиента и принимал только те сертификаты, которые вы развернули на своих клиентах. Если кто-то / что-то пытается подключиться, не имеет этого сертификата клиента, он не сможет установить сеанс SSL, и соединение не будет установлено. Предполагая, что вы контролируете законных клиентов и серверы, вам не нужен сертификат, выданный CA здесь; просто используйте самозаверяющие сертификаты, поскольку вы управляете доверием сертификатов как на стороне клиента, так и на стороне сервера.

Теперь вы говорите, что действительно трудно помешать кому-либо выполнить реинжиниринг вашего клиента и восстановить ваши учетные данные (в данном случае закрытый ключ, принадлежащий сертификату клиента). И ты прав. Обычно вы храните этот ключ (и сертификат) в хранилище ключей некоторого типа (KeyStore, если вы используете Android), и это хранилище ключей будет зашифровано. Это шифрование основано на пароле, поэтому вам нужно либо (1) сохранить этот пароль в вашем клиенте, либо (2) запросить пароль у пользователя при запуске вашего клиентского приложения. Что вам нужно сделать, зависит от вашего варианта использования. Если (2) приемлемо, то вы защитили свои учетные данные от обратного инжиниринга, поскольку он будет зашифрован, и пароль нигде не будет храниться (но пользователь должен будет вводить его каждый раз). Если вы сделаете (1), то кто-то сможет провести обратный инжиниринг вашего клиента, получить пароль, получить хранилище ключей, расшифровать закрытый ключ и сертификат, а также создать другого клиента, который сможет подключаться к серверу.

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

Answer 2

Вы выполняете шаг аутентификации OAuth по самому SSL? Это предотвращает все виды отслеживания, хотя это означает, что вам нужно быть осторожным, чтобы поддерживать сертификат вашего сервера OAuth в актуальном состоянии. (Обратите внимание, что сервер OAuth может иметь общедоступную идентификацию SSL; по-прежнему невозможно подделать даже смутно разумные усилия. Только секретный ключ необходимо хранить в секрете.)

Тем не менее, вам нужно быть более осторожным в отношении того, от чего вы защищаете. Почему люди вообще должны использовать ваш клиентский код? Почему это должно быть «секретно»? Проще отдать это и поместить смарты (включая проверку личности при входе) на ваш сервер. Если кто-то хочет написать свой собственный клиент, пусть. Если кто-то хочет глупо махнуть своим аккаунтом публично, возложите на него расходы, которые они несут из-за своей глупости ...