Как проверить происхождение активации веб-службы

Предположим, у вас есть мобильное приложение (Windows Phone или Android), которое соединяет ваш сервер с SOAP.

Для упрощения, скажем, у нас есть веб-сервис, реализованный на С#. Сервер предоставляет следующий метод:

[WebMethod]
public string SayHallo() { return "Hallo Client"; }

С точки зрения сервера вы не можете определить, является ли вызывающее устройство вашим мобильным приложением или разработчиком, пытающимся отладить ваш веб-сервис или хакер, пытающийся перепроектировать/использовать ваш back-end.

Как можно определить, что источником вызова веб-службы является приложение? так как любой, кто имеет WSDL, может вызывать WS.

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

  • Внедрить HTTPS на сервере, чтобы сообщения проходили зашифрованными, а опасность подслушивания снижалась.
  • Подпишите запросы на стороне клиента с помощью алгоритма дайджеста/хэширования, проверьте подпись на сервере и отклоните сообщения, которые не были правильно подписаны.
  • Запись пользовательских заголовков в HTTP-запросе. В любом случае можно моделировать заголовки.

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

Любые идеи, как заставить метод SayHallo() отвечать ТОЛЬКО на запрос, сделанный из моего мобильного приложения?

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

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

Спасибо за ваши идеи.

Ответы

Ответ 1

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

Ответ 2

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

Быстрый поиск в Google показал следующее:

http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

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

Ответ 3

В целом модель выглядит следующим образом:

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

Итак, если вам интересно, как это работает в случае банковских приложений и т.д., в основном, как он ломается: (1) Клиент и сервер устанавливают безопасный канал, такой как общий секретный ключ, используя сервер открытый ключ, (2) Клиент аутентифицируется через этот защищенный канал с использованием другого механизма.

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

  • Это означает, что каждому пользователю вашего приложения доверяют. В условиях безопасности они являются частью вашей доверенной вычислительной базы.
  • Попытка достичь такой цели БЕЗ рассмотрения пользовательской/пользовательской вычислительной платформы как доверенной по существу является целью DRM; и хотя он достаточно хорош, чтобы сэкономить деньги для издателей музыки, он нигде не приближается к достаточно хорошему для чего-то действительно чувствительного.

В общем:

  • Проблема, с которой вы специально смотрите, очень сложно решить, если вы ищете очень сильные свойства безопасности.
  • Вероятно, вам не нужно решить эту проблему.
  • Если вы дадите нам еще какой-то контекст, мы сможем дать вам более конкретные советы.

Ответ 4

В дополнение к уже предоставленным ответам, как насчет использования схемы типа входа с уникальным идентификатором телефона и паролем? Попросите пользователя зарегистрироваться в своем "back-end" и каждый раз, когда транзакция должна выполняться с помощью внешнего сервера, требуется пароль или у вас есть возможность автоматически войти в систему.

Ответ 5

Вы можете использовать следующий способ защиты и отслеживания ваших запросов на сервере.

  • Вы можете заставить мобильных или веб-клиентов отправлять вам Custom Headers тип устройства при доступе к вашему веб-сервису через REST methods

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

  • Если вам нужна более совершенная защита, вы можете использовать OAuth 2.0, чтобы защитить свой веб-сервис.

Ответ 6

Поскольку ваше исходное приложение будет Android или Windows Phone приложениями, один из них будет относительно легким для того, чтобы захотеть хакеру отлаживать. в любом случае вы будете запускать код на компьютере, на котором у вас нет контроля, поэтому никакие трюки ssl или проверка подписи не помогут решить вашу фундаментальную проблему.

Единственный способ борьбы с угрозой от него - НЕ ДОСТИГАТЬ КЛИЕНТА. убедитесь, что вход, исходящий от клиентов, действителен, прежде чем действовать на него, если вы делаете игру, - что он сопровождается действительным маркером безопасности и т.д.

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