Repository navigation
Rule request: AvoidSecureStringDisclosure #1997
Description
Activity
- changed the title
[-]Rule request: `AvoidUsingConvertFromSecureStringToPlainText`[/-][+]Rule request: `AvoidSecureStringLeaks`[/+]on Apr 30, 2024 - changed the title
[-]Rule request: `AvoidSecureStringLeaks`[/-][+]Rule request: `AvoidSecureStringDisclosure`[/+]on May 1, 2024 Thanks iRon7 , we would want more comments here on the plan for implementation and design open for community discussion before opening a PR. We don't have any plans to open rules along these lines at this time but have left it up for grabs.
Reacted by iRon7The thing with a
SecureStringis that it might be reasonable secure by itself but any automated (scripted) usage, is not, because:- Putting something (a string) in it, is unsecure. The only secure ways to convert a string to a
SecureString, are:Read-Host -AsPlainText(which isn't unattended)- Create a
SecureStringby injecting (random) characters (which can't be reused as you should kill the source) - Use a
[SecureString]parameter (pushing the conversion to the front of the automated process)
- Get something (a string) out of it, is unsecure as it might leave memory traces or even logging traces. Besides:
- any script that is about do something with the unencrypted string (like passing it to a website,
Register-ScheduledTask, etc.) is even more doubtful - these scripts are easily to fool by spoofing the target that receives the plain text password. (see e.g.: #17135)
- any script that is about do something with the unencrypted string (like passing it to a website,
Bottom line; the best way to handle a
SecureStringis: don't, meaning that you might only pass it thru.
Which is quiet useless as this means that you might as well push it out of your script.
And if you look at the process as a whole and completely push the "ConvertTo-SecureString" to the front of the process and "ConvertFrom-SecureString" to the end of the process, it is no different than relying on the PC - or User credentials (such as certificates or Windows authentication) that eventually runs your script.Reacted by Francisco Palomino- Putting something (a string) in it, is unsecure. The only secure ways to convert a string to a
As for AvoidUsingConvertToSecureStringWithPlainText it should be avoided to retrieve a PlainText password from a
SecureStringas it might leave memory trials (or even logging trails).Besides, the action that follows and requires the plaintext password is likely vulnerable from a security aspect.
This will also include the common used statements as:
(see: https://stackoverflow.com/a/28353003/1701026)
and (see: https://stackoverflow.com/a/40166959/1701026):
The general approach of dealing with credentials is to avoid them and instead rely on other means to authenticate, such as certificates or Windows authentication.
Proposed technical implementation details (optional)
Create rules to check for the above mentioned unsafe statements.