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

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

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


http mfc authenticity
person nnc    schedule 26.12.2009    source источник
comment
любимый: У меня есть кое-какие мысли, но на самом деле я не крипто-парень. Надеюсь, кто-нибудь из них пройдёт мимо и даст окончательный ответ. Кстати, вы могли бы получить более точные ответы, если бы предложили стратегию, а затем попросили сообщество подвергнуть ее критике.   -  person John Knoeller    schedule 27.12.2009
comment
Помните, никогда не доверяйте своим пользователям, они лживы и злонамеренны.   -  person Ben Shelock    schedule 27.12.2009

Ответы (4)


arrow_upward
9
arrow_downward

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

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

person nitzmahone    schedule 26.12.2009
comment
Теперь я понимаю, что ты прав, и все это было бы просто ложным чувством безопасности. Но поможет ли сертификат клиента здесь вообще, если пользователь на самом деле будет пытаться обмануть систему, загружая поддельные/сфабрикованные данные? - person nnc; 27.12.2009
comment
Только в том, что вы будете довольно точно знать, кто это делал, и вы можете отозвать их сертификат, если они компрометируют систему (при условии, что вы правильно настроили свои CRL / OCSP в ЦС, который его выдал, и на проверяющем сервере). - person nitzmahone; 27.12.2009
comment
Правильно, тот, кто контролирует клиент, может делать все, что угодно, в том числе обойти все ваши меры безопасности. Это может принимать форму изменения переменных программы в памяти, от чего очень трудно защититься (на практике невозможно), включая потенциальное выполнение его на виртуальной машине и изменение памяти извне виртуальной машины (где приложение, выполняющее изменение, не может быть обнаруженным). Лучше всего для OP попытаться проверить загрузку, чтобы ничего ПЛОХОГО не могло произойти, даже если будет загружен мусор - в любом случае это может произойти однажды из-за ошибки на стороне клиента. - person MarkR; 27.12.2009

arrow_upward
2
arrow_downward

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

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

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

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

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

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

person bobince    schedule 26.12.2009

arrow_upward
2
arrow_downward

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

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

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

person Community    schedule 26.12.2009
comment
Основываясь на ответах здесь, я понял, что нет реального решения этой проблемы, поскольку пользователь - единственный, кто получает что-то, играя в систему, поэтому я не думаю, что закрытый ключ с парольной фразой помогает в этом случае? - person nnc; 27.12.2009
comment
Что ж, если пользователь не видит никакого вреда в том, что частное подписание кто-то еще своевременно загружает его, или если интеграция его ключа в другое приложение дает ему преимущество, вы мало что можете сделать. - person Alex Jasmin; 27.12.2009

arrow_upward
0
arrow_downward

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

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

person Aviad P.    schedule 26.12.2009
comment
Кто бы ни проголосовал за это, пожалуйста, укажите причину. В оригинальном плакате конкретно говорилось, что он контролирует среду вызова, то есть клиента, и если да, то мой ответ верен. - person Aviad P.; 27.12.2009
comment
Я не DV, но он также предположил, что знает, что злоумышленник может извлечь ключ, что означает, что он фактически не контролирует среду выполнения. Я думаю, они хотели сказать, что они просто строят и клиент, и сервер. - person EricLaw; 27.12.2009
comment
Изначально я был неясен и обновил вопрос, чтобы отразить, что мы фактически не контролируем среду выполнения клиентского приложения. - person nnc; 27.12.2009