Как обеспечить загрузку HTTP с подлинного исполняемого файла
Мы находимся в процессе написания собственного приложения Windows (MFC), которое будет загружать некоторые данные в наше веб-приложение. Приложение Windows позволит пользователю войти в систему и после этого будет периодически загружать некоторые данные в наше веб-приложение. Загрузка будет осуществляться через простой HTTP POST в наше веб-приложение. Меня беспокоит то, как мы можем гарантировать, что загрузка действительно происходит из нашего приложения, а не из curl или чего-то в этом роде. Я предполагаю, что мы смотрим на какое-то шифрование с открытым / закрытым ключом здесь. Но я не уверен, сможем ли мы как-то просто вставить открытый ключ в наш исполняемый файл win-приложения и покончить с этим. Или этот открытый ключ будет слишком легко извлечь и использовать за пределами нашего приложения?
Как бы то ни было, мы строим обе стороны (клиент и сервер), поэтому практически все, что угодно - это вариант, но он должен работать через HTTP(S). Тем не менее, мы не контролируем среду исполнения приложения win (client), плюс пользователь, который запускает приложение в своей системе, является единственным, кто может что-то получить, играя в систему.
4 ответа
В конечном счете, невозможно доказать идентичность приложения таким образом, когда оно работает на машине, которой вы не владеете. Вы можете вставлять ключи, играть с хэшами и контрольными суммами, но в конце концов все, что зависит от кода, запущенного на чужой машине, может быть подделано. Ключи могут быть извлечены, код может быть перепроектирован - это все безопасность через неизвестность.
Потратьте свое время, работая над проверкой и очисткой данных, и, если вы действительно хотите что-то защитить, обеспечьте конечного пользователя сертификатом клиента. Все остальное - пустая трата времени и ложное чувство безопасности.
Вы не можете контролировать двоичные файлы после распространения приложения. Если вся логика подписи и шифрования находится в вашем исполняемом файле, ее можно извлечь. Умные программисты выяснят код и создадут совместимые системы, когда для этого будет достаточно мотивации. Вот почему DRM не работает.
Сложная система, связывающая ключ с MAC-адресом ПК, например, обязательно даст сбой.
Не доверяйте конкретному исполняемому файлу или системе, а доверяйте своим пользователям. Поручите каждому из них файл с закрытым ключом, защищенный парольной фразой, и объясните им, как этот ключ идентифицирует их как отправителей содержимого вашего сервиса.
Самое лучшее, что вы могли бы сделать - это использовать HTTPS с клиентскими сертификатами. Предположительно с интерфейсом WinHTTP.
Но я не уверен, сможем ли мы как-то просто вставить открытый ключ в наш исполняемый файл win-приложения и покончить с этим.
Если клиент должен идентифицировать себя на сервере, это должен быть встроенный закрытый ключ.
Или это будет слишком легко извлечь и использовать за пределами нашего приложения?
Если вы не контролируете среду выполнения клиентского приложения, все, что может сделать ваше приложение, может быть проанализировано, автоматизировано и воспроизведено злоумышленником, который контролирует эту среду.
Если хотите, вы можете поместить запутывающие слои вокруг процедуры коммуникации, но вы никогда не решите проблему. Многопользовательские игры пытались сделать это в течение многих лет, чтобы бороться с мошенничеством, но в итоге это просто гонка вооружений, которая никогда не может быть выиграна. У Blizzard гораздо больше ресурсов, чем у вас, и они тоже не могут этим управлять.
Поскольку вы управляете клиентом, вы также можете встроить ключ в приложение и убедиться, что пользователи не имеют доступа для чтения к образу приложения - вам необходимо разделить логику на 2 уровня - 1, что пользователь запускает другой, который подключается к сервису через HTTP(S) - так как пользователь всегда будет иметь доступ для чтения к приложению, которое он запускает.
Если я правильно понимаю, данные отправляются автоматически после входа пользователя в систему - похоже, нужна только служебная часть.