2017-05-30 4 views
1

J'ai une application qui prend une chaîne de la boîte de texte Windows Forms et la passe à une API qui utilise une chaîne comme paramètre. Je vois que la chaîne peut toujours être interrogée à partir de la mémoire de processus une fois la tâche terminée. J'ai rencontré des suggestions pour utiliser SecureString pour les capacités de gestion de mémoire de chaîne. Mais, si je comprends bien, le but de la chaîne est vaincu si la chaîne sécurisée est construite à partir d'une chaîne ou si la valeur de la chaîne sécurisée est finalement stockée dans une chaîne.Comment supprimer une chaîne de la mémoire de processus?

S'il vous plaît suggérer quelle est la meilleure solution possible.

+0

est-ce crypté sur le fil? Si non, pourquoi êtes-vous même préoccupé par cela en mémoire? –

+0

Tout paramètre est transmis aux méthodes de la pile d'exécution. Lorsque la méthode est terminée, le point de pile d'exécution est restauré à l'emplacement avant l'appel de la méthode. Ainsi, toutes les variables utilisées par les méthodes sont toujours sur la pile et non accessibles. La méthode appelante doit détruire la variable avant de retourner pour retirer l'objet de la pile. – jdweng

+0

Si elle provient d'un contrôle WinForms 'TextBox', alors il y a déjà un nombre inconnu/inconnaissable de copies de cette chaîne qui se cache partout. Vous ne pouvez pas réparer cette fuite. Réorganisez-le pour utiliser 'SecureString' ou acceptez que quelqu'un disposant d'un accès suffisant aux machines sur lesquelles ce code est exécuté * pourrait potentiellement lire ces données depuis la mémoire du processus. Mais gardez à l'esprit - quelqu'un avec ce niveau d'accès pourrait facilement avoir installé un keylogger de toute façon. –

Répondre

5

SecureString n'est pas considéré comme sécurisé. Si vous besoin pour ce faire, vous pouvez soit utiliser un char[] et remplacer les données une fois terminé, ou vous pouvez utiliser le code unsafe pour remplacer un string lorsque vous avez terminé (juste ... espérons qu'il n'a pas été interné ou une référence partagée) ; Notez que cela s'applique partout dans la pile d'appels. Notez que le système d'exploitation peut avoir copié la page pour diverses raisons et il peut même être sur le disque (fichier d'échange) si la mémoire n'était pas très soigneusement allouée.

Cependant, les outils d'analyse mémoire du temps sont un facteur dans une application WinForms, il serait plus facile d'utiliser un enregistreur de frappe, ou tout simplement prendre une clé et menacer quelqu'un pour le mot de passe:

+0

Par curiosité, pourriez-vous préciser que ce n'est pas considéré comme sécurisé? – Rob

+1

@Rob il est bien connu comment inverser trivialement et a été pendant plus d'une décennie; "HawkEye" pourrait faire cela au moins aussi loin que 2006: https://corneliutusnea.wordpress.com/2006/10/25/hawkeye-i-can-see-your-securestrings/ - finalement, puisque l'objet doit exposer une méthode pratique de récupérer les données sous-jacentes, tout code malveillant peut simplement exploiter que –

+1

@Rob: De la [MSDN] (https://msdn.microsoft.com/fr-fr/library/system.security.securestring (v = vs.110) .aspx # HowSecure): "Globalement, SecureString est plus sécurisé que String car il limite l'exposition des données de chaîne sensibles, mais celles-ci peuvent toujours être exposées à tout processus ou opération ayant accès à la mémoire brute. Au lieu d'utiliser SecureString pour protéger les mots de passe, il est recommandé d'utiliser un descripteur opaque pour les informations d'identification stockées en dehors du processus, par exemple un processus malveillant s'exécutant sur l'ordinateur hôte, un vidage de processus ou un fichier d'échange. " – Brian