Как обеспечить a.Net приложение является подлинным?


В клиент-серверном приложении как сервер может знать, что запрос исходит от подлинного приложения, а не от его подделанной копии? Я до сих пор не разработал ни клиентское, ни серверное приложение. Решением может быть обычный сокет, wcf, IIS hosted или что-то еще.

5 4

5 ответов:

На самом деле нет никакого способа. Все, что вы можете попросить приложение предоставить, мошенническое приложение может подделать. В конечном счете ответ заключается в том, что вы не должны доверять ни одному клиентскому приложению. Вы можете доверять пользователям, если они прошли проверку подлинности, но сам клиент на 100% ненадежен.

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

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

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

  • Аутентификация. Цифровые подписи, внутренние хэши и данные, предоставленные пользователем, делают более вероятным то, что вы говорите с тем, с кем вы думаете, что вы говорите. Однако программы могут быть захвачены вредоносными программами, которые используют ваша клиентская сборка как марионетка. Даже если в вашем коде нет общедоступных крючков, вредоносная программа или Хак, получившие разрешение на запуск с помощью SkipVerification, могут отразиться в вашей сборке и вызвать закрытые члены.

  • Мониторинг безопасности. Клиенты, которые вы создаете, могут периодически спрашивать Windows о том, у кого в данный момент есть крючки памяти в ее коде. Если кто-то прослушивает ваш клиент или использует его, что ваш клиент не распознает или что сервер имеет идентифицированный как враждебный, клиент может аварийно завершить работу и сгореть, и сервер знает, что этот клиент был скомпрометирован. Это, как правило, трудно обойти, но знание процедуры безопасности может помочь скомпрометировать его, либо работая быстро, чтобы избежать "патрулей" безопасности, либо захватывая крючки вашего клиента в Windows, чтобы спросить о подозрительной активности.

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

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

Конечно, это только защищает канал, но не само клиентское приложение. Единственный способ гарантировать, что клиент полностью защищен от несанкционированного доступа, - это задействовать физический контроль безопасности, который защитите запущенное приложение (т. е. Банкоматы и POS-автоматы).

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

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

Для защиты передаваемых данных от атак типа "человек в середине" (Data snooping). нужно зашифровать данные. Это может быть достигнуто с помощью SSL-связи между клиентом и сервером, при условии, что выполняются некоторые основные проверки. Клиент должен убедиться, что сертификат подписан доверенным корневым центром сертификации, не истек и выдается по URL-адресу, соответствующему вызываемому.

Удаленная проверка подлинности приложений невозможна.

Вы можете аутентифицировать пользователей и предотвращать атаки типа "Человек посередине". Но если вы думаете, что аутентифицированный пользователь сам враждебен и может вмешаться в приложение,то нет никакого способа предотвратить это.

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