Как удалить строку из памяти процесса?

У меня есть приложение, которое берет строку из текстового поля Windows Forms и передает ее в API, который использует строку в качестве параметра. Я вижу, что строку все еще можно запросить из памяти процесса после завершения задачи. Я сталкивался с предложениями использовать SecureString для возможностей управления строковой памятью. Но, если я правильно понимаю, цель строки теряется, если безопасная строка построена из строки или значение защищенной строки в конечном итоге хранится в строке.

Пожалуйста, предложите, что является лучшим возможным решением.


person Ishan    schedule 30.05.2017    source источник
comment
он зашифрован на проводе? если нет, то почему вы вообще беспокоитесь об этом в памяти?   -  person Mitch Wheat    schedule 30.05.2017
comment
Любой параметр передается методам в стеке выполнения. Когда метод завершается, точка стека выполнения восстанавливается обратно в положение, предшествующее вызову метода. Таким образом, любые переменные, используемые методами, все еще находятся в стеке и недоступны. Вызывающий метод должен будет уничтожить переменную, прежде чем вернуться, чтобы удалить объект из стека.   -  person jdweng    schedule 30.05.2017
comment
Если это исходит из элемента управления WinForms TextBox, то уже повсюду скрывается неизвестное/неизвестное количество копий этой строки. Вы не можете исправить эту утечку. Либо перепроектируйте это, чтобы использовать SecureString повсюду, либо смиритесь с тем, что кто-то с достаточным доступом к машине (машинам), на которой работает этот код, может потенциально прочитать эти данные из памяти процесса. Но имейте в виду - кто-то с таким уровнем доступа все равно легко мог установить кейлоггер.   -  person Damien_The_Unbeliever    schedule 30.05.2017


Ответы (1)


SecureString не считается безопасным. Если вам необходимо сделать это, вы можете либо использовать char[] и перезаписать данные после выполнения, либо вы можете использовать код unsafe, чтобы перезаписать string после завершения (просто... надеюсь, что он не был интернирован или общая ссылка); обратите внимание, что это применимо везде в стеке вызовов. Обратите внимание, что ОС могла скопировать страницу по разным причинам, и она может даже находиться на диске (файл подкачки), если память была очень выделена неаккуратно.

Однако к тому времени, когда инструменты анализа памяти станут важным фактором в приложении winforms, будет проще использовать кейлоггер или просто взять гаечный ключ и угрожать кому-то паролем:

person Marc Gravell    schedule 30.05.2017
comment
Из любопытства, не могли бы вы уточнить, что это не считается безопасным? - person Rob; 30.05.2017
comment
@Rob хорошо известно, как тривиально это изменить, и это было уже более десяти лет; HawkEye мог сделать это по крайней мере еще в 2006 году: corneliutusnea.wordpress.com/2006/10/25/ - в конечном счете, поскольку объект должен предоставлять удобный метод получения базовых данных, любой вредоносный код может просто использовать этот - person Marc Gravell; 30.05.2017
comment
@Rob: из MSDN: в целом, SecureString более безопасен, чем String, поскольку ограничивает доступ к конфиденциальным строковым данным. Однако эти строки могут по-прежнему подвергаться воздействию любого процесса или операции, которые имеют доступ к необработанной памяти, например вредоносного процесса, работающего на главном компьютере, дампа процесса или файла подкачки, доступного для просмотра пользователем. Вместо использования SecureString для защиты паролей рекомендуется использовать непрозрачный дескриптор для учетных данных, которые хранятся вне процесса. - person Brian; 31.05.2017