Rule request: AvoidSecureStringDisclosure

[iRon7]

As for AvoidUsingConvertToSecureStringWithPlainText it should be avoided to retrieve a PlainText password from a SecureString as it might leave memory trials (or even logging trails).

$Password = $SecureString | ConvertFrom-SecureString -AsPlainText

This will also include the common used statements as:
(see: https://stackoverflow.com/a/28353003/1701026)

$SecurePassword = ConvertTo-SecureString $PlainPassword -AsPlainText -Force
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($SecurePassword)
$Password = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
[Runtime.InteropServices.Marshal]::ZeroFreeBSTR($BSTR)

and (see: https://stackoverflow.com/a/40166959/1701026):

$Password = (New-Object PSCredential 0, $SecurePassword).GetNetworkCredential().Password

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.

[SydneyhSmith]

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.

[iRon7]

The thing with a SecureString is 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 SecureString by 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)

Bottom line; the best way to handle a SecureString is: 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.