Как убедиться, что HTTP-загрузка была произведена из аутентичного исполняемого файла

Question

Мы находимся в процессе написания собственного приложения для Windows (MFC), которое будет загружать некоторые данные в наше веб-приложение.Приложение Windows позволит пользователю войти в систему, и после этого оно будет периодически загружать некоторые данные в наше веб-приложение.Загрузка будет осуществляться через простой HTTP POST в наше веб-приложение.Меня беспокоит, как мы можем гарантировать, что загрузка действительно была произведена из нашего приложения, а не из curl или чего-то подобного.Я предполагаю, что здесь мы имеем дело с каким-то видом шифрования с открытым / закрытым ключом.Но я не уверен, можем ли мы каким-то образом просто встроить открытый ключ в наш исполняемый файл win app и покончить с этим.Или этот открытый ключ было бы слишком легко извлечь и использовать за пределами нашего приложения?

В любом случае, мы создаем обе стороны (клиент и сервер), так что практически все возможно, но это должно работать через HTTP (Ы).Однако мы не контролируем среду выполнения win (клиентского) приложения, плюс пользователь, который запускает приложение в своей системе, является единственным, кто может что-то выиграть, играя в систему.

Answer 1

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

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

Answer 2

Пожалуй, лучшее, что вы могли бы сделать, - это использовать HTTPS с клиентскими сертификатами.Предположительно , с WinHTTPинтерфейс пользователя.

Но я не уверен, можем ли мы каким-то образом просто встроить открытый ключ в наш исполняемый файл win app и покончить с этим.

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

Или это было бы слишком легко извлечь и использовать за пределами нашего приложения?

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

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

Answer 3

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

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

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

Answer 4

Поскольку вы управляете клиентом, вы могли бы также встроить ключ в приложение и убедиться, что у пользователей нет доступа на чтение к образу приложения - вам нужно будет разделить логику на 2 уровня - 1, который запускает пользователь, другой, который подключается к службе по HTTP (S) - поскольку пользователь всегда будет иметь доступ на чтение к приложению, которое он запускает.

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