Как передавать конфиденциальные данные между процессами в Windows?

Я хотел бы передать информацию об имени пользователя и пароле из одного процесса в другой процесс, работающий на том же сервере в Windows. Каков наилучший подход для обеспечения такой передачи безопасным способом? Один простой подход состоит в том, чтобы скопировать пароли в файл, а затем дать другому процессу прочитать файл, а затем удалить файл после того, как он будет прочитан. Хотя это просто, я обеспокоен тем, что он безопасен, поскольку кто-то все еще может получить доступ к этому файлу, даже если он живет только в течение короткого периода времени, а также есть вероятность того, что файл будет пропущен, если другой обрабатывает ошибки или аварийно завершает работу. IPC, такие как сокеты и именованные каналы, кажутся излишними для решения этой проблемы. Я больше склоняюсь к использованию файлов с отображением памяти, как описано в этой ссылке ниже, в которой говорится о совместном использовании памяти между процессами. Это правильный подход? Кроме того, рекомендуется ли заполнять память фиктивными данными перед освобождением/стиранием, чтобы предотвратить удаление данных из этой области памяти процессами румян?

http://msdn.microsoft.com/en-us/library/aa366551(VS.85).aspx


person msvcyc    schedule 11.06.2009    source источник
comment
Ваш первый заказ должен заключаться в том, чтобы убедиться, что вы шифруете свои данные. Затем поработайте над тем, как переходить между процессами. Работайте исходя из предположения, что независимо от того, какой метод вы используете для передачи данных между процессами, кто-то сможет найти данные.   -  person Jeremy    schedule 12.06.2009
comment
Если я выберу шифрование данных, у меня будет большая головная боль при управлении ключами. Не кажется ли вам, что это большой перебор для такой простой задачи?   -  person msvcyc    schedule 12.06.2009


Ответы (2)


RPC — ваш друг здесь (я бы не стал использовать именованные каналы для передачи защищенных данных, потому что у них есть серьезные проблемы (поскольку они работают в глобальном пространстве имен и, следовательно, уязвимы для атак на корточки)).

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

Не забудьте надежно обнулить память, когда закончите ее использовать (иначе она может сохраниться на диске).

Если вы ДЕЙСТВИТЕЛЬНО хотите использовать шифрование, используйте CryptProtectMemory, который будет шифровать данные таким образом, чтобы их можно было использовать для IPC.

person ReinstateMonica Larry Osterman    schedule 12.06.2009
comment
Абсолютно. Не используйте именованные каналы или файл с отображением памяти. С любой из этих технологий вы, вероятно, создадите более серьезную уязвимость, чем та, которую вы пытаетесь смягчить. - person Chris Clark; 12.06.2009
comment
Запрос: как RPC позволяет избежать проблемы с присвоением имен? - person Richard; 12.06.2009
comment
Если вы привязываетесь к статической конечной точке (ncalrpc:\\myapp), у вас возникают проблемы с приседанием, но если вы привязываетесь к динамической конечной точке, то их нет (вам нужно быть немного осторожным, но это возможно). - person ReinstateMonica Larry Osterman; 13.06.2009
comment
Компоненты безопасности Windows также используют LPC (локальное межпроцессное взаимодействие) blogs.msdn.com/b/ntdebugging/archive/2007/07/26/ - person ChristianWimmer; 19.08.2014
comment
CryptProtectMemory выглядит интересно... есть ли аналоги на других платформах? - person Trejkaz; 04.08.2017

Используйте какой-нибудь IPC, который (1) не имеет резервной копии на диск, (2) поддерживает ACL.

Казалось бы, это указывает на именованные каналы.

С другой стороны, DCOM и WCF поддерживают шифрование содержимого.

person Richard    schedule 11.06.2009
comment
Действительно страшно осознавать, что только именованные каналы, wcf и DCOM — единственные варианты для такой простой задачи. Я все еще на стороне отображения памяти. Есть мысли по этому поводу? - person msvcyc; 12.06.2009
comment
@msvcyc: Во-первых, безопасность никогда не бывает простой, во-вторых, на основе тех критериев, которые я вижу. Существуют и другие варианты (например, SSL), но это означает реализацию собственного контроля доступа. - person Richard; 12.06.2009