PowerShell / PowerShell/PSScriptAnalyzer
Rule request: `AvoidSecureStringDisclosure`
還沒有人認領這個 Issue。
- 主要語言
- C#
- 星號
- 2.2k
- 分支
- 414
- 平均合併
- 13 小時 1 分鐘
- 30 天內合併 PR
- 2
描述
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
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)
$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.
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
首先定位現有的 PSScriptAnalyzer 規則實作和測試,然後比較它們對 ConvertFrom-SecureString、SecureStringToBSTR 和 PSCredential.GetNetworkCredential() 的處理方式。當不安全的 SecureString-to-plaintext 模式能夠被可靠地回報,且相應的分析器測試涵蓋 issue 中的範例時,工作就完成了。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- csharp, powershell
- 領域
- security, tooling
- Issue 類型
- 功能
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 活躍度
- 停滯
- 描述清晰度
- 基本清楚
- 新手友好度
- 35/100