Как обезопасить свой Web API - MVC4 с Android/прошивкой приложения

Question

Я читал немало вопросов здесь, на SO об обеспечении безопасности с использованием ключей API веб-интерфейсы API, маркеры, HMAC ЭСТ и не нашли ответ, который я ищу для.

Я работаю над приложением проекта MVC4 веб с интернет и интранет-сайтов, веб-API и Android/IOS приложений.

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

Что было бы лучшим способом обеспечения безопасности этого api, так что только мои приложения могут его использовать? То, что кажется таким простым запросом, очень сложно начать.

Я смотрел на пост здесь на SO, используя HMAC и несколько других, но ни один из них не звучал, как они будут соответствовать здесь, более чем вероятно, я просто что-то отсутствует.

Является ли HMAC способ перехода или сертификаты клиентов более подходят для этой ситуации?

Должен ли я использовать SSL и какой-либо ключ API?

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

Я был бы более чем счастлив предоставить более подробную информацию по запросу.

Answer 1

Создайте ключ для каждого из ваших приложений и попросите их передать ключ в каждом запросе в качестве токена. Затем ваш сервер может проверить ключ и аутентифицировать запрос.

Посмотрите на Basic Authentication модуль с сайта ASP.NET. Образец использует «базовый» в качестве схемы авторизации, но вместо этого вы можете вместо этого использовать «токен».

private static void OnApplicationAuthenticateRequest(object sender, EventArgs e) 
    { 
     var request = HttpContext.Current.Request; 
     var authHeader = request.Headers["Authorization"]; 
     if (authHeader != null) 
     { 
      var authHeaderVal = AuthenticationHeaderValue.Parse(authHeader); 

      // RFC 2617 sec 1.2, "scheme" name is case-insensitive 
      if (authHeaderVal.Scheme.Equals("token", 
        StringComparison.OrdinalIgnoreCase) && 
       authHeaderVal.Parameter != null) 
      { 
       AuthenticateUser(authHeaderVal.Parameter); 
      } 
     } 
    } 

После того, как у вас есть модуль Basic Auth в месте вы можете просто декорировать любые действия или контроллеры с атрибутом Authorize и перенаправит запрос на обработчики Basic Auth.

namespace webapi.Controllers 
{ 
    [Authorize] 
    public class SensitiveDataController : ApiController 
    { 
     ... 
    } 
} 

Насколько по проводам вы MUST использование SSL при использовании базовой аутентификации, как ключ будет передаваться в виде обычного текста.

Answer 2

Я работаю над аналогичным проектом, в котором я назначить уникальные ключи API для каждого пользователя или клиентского приложения доступ к моему API. Я не эксперт по безопасности, но я бы рекомендовал вам использовать SSL и генерировать уникальные ключи API для ваших приложений для Android и iOS. С SSL данные, передаваемые в ваш API, будут зашифрованы и защищены.

Answer 3

Вы можете использовать FormsAuthentication. Шифруйте билет и убедитесь, что machineKey одинаково в обоих конфигурационных файлах. См. this и this. Это позволит использовать одинаковые учетные данные пользователя между веб-приложением и api. В этом случае модуль FAM ASP.NET установит личность.

Для ключа api, посмотрите на hawk scheme. Он использует общий симметричный ключ. Тем не менее, Hawk является полнофункциональным, и пока он не достигнет версии 1.0, он, скорее всего, изменится. Тем не менее, это даст вам хорошее представление о внедрении безопасности на базе HMAC. У меня есть реализация .NET here для Hawk.И есть один от Pablo. В этом случае вам нужно будет написать обработчик сообщений, чтобы установить идентификатор для приложения-потребителя.

Answer 4

В общем случае для приложения с высоким трафиком у всего вышеприведенного ответа есть недостаток, который могут легко использовать многие злоумышленники: С сломанным iPhone, вы можете разбить SSL - не на свой сервер, но когда у вас есть приложение на своем телефоне, они могут по крайней мере проанализировать пакеты, которые вы отправляете.

Лучший способ избежать этого (на мой взгляд) использовать «по времени пароли» - настоящие по времени пароли.

Как вы можете генерировать эти одноразовые пароли?

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

A2. Уже api_key, что вы будете использовать для хэширования

Теперь, если вы хотите послать пакет к вашему API, вы сделали следующее:

B1. Построить свой обычный пакет, вот пример некоторой JSon полезной нагрузки:

var payload = {"hello":"world"}

B2. Hash your var hashed_payload = hash(payload), используя вашу любимую функцию хеширования

B3. Создайте один раз пароль для этого пакета:

var otp = hash(salt & hashed_payload & device_token & api_key)

Теперь у вас есть все, что нужно, чтобы отправить на сервер:

В заголовках, вам необходимо отправить otp, salt и device_token как Что ж!

На сервере вы выполните те же действия, что и B1-3, и сравните свой результат хэширования с предоставленным клиентом. После этого вы должны убедиться, что вы «запретили» этот salt для этого device_token во избежание повторных атак.

У этого метода все еще есть один недостаток, но от злоумышленников требуется гораздо больше работ: Они могут найти ваш api_key в скомпилированном коде.