我在 PowerShell 中使用哈希表,我注意到一些与访问项目相关的奇怪行为。众所周知,PowerShell 至少允许三种不同的方式将值分配给哈希表条目:
$hashtable["foo"] = "bar" #1
$hashtable.Item("foo") = "bar" #2
$hashtable.foo = "bar" #3
同时,我们使用#3 语法来访问 Hashtable 对象本身的属性,例如Count
, Keys
,Values
等。如果我们添加一个键与内部属性名称冲突的项,PowerShell 允许我们这样做,并且我们实际上不再能够读取属性的值(使用反射除外)。
我猜在密钥来自不可靠来源(例如来自外部文件或网络)的情况下,这可能会对流控制产生不良影响,并且可能被恶意用户利用。
这个片段演示了这个问题:
function Get-HashtableProperties($hashTable, $header)
{
"{0} {1} {0}" -f ("-" * 10), $header
"Count : {0}" -f $hashtable.Count
"Keys.Count : {0}" -f $hashtable.Keys.Count
"Values.Count : {0}" -f $hashtable.Values.Count
"Actual Count (Reflection) : {0}" -f $hashtable.GetType().GetProperty("Count").GetValue($hashtable)
"`nItems (Keys iteration):"
$hashtable.Keys | ForEach-Object { " [ {0} = {1} ]" -f $_, $hashtable.Item($_) }
"`nItems (Enumerator iteration):"
$enumerator = $hashTable.GetEnumerator()
while ($enumerator.MoveNext())
{
" [ {0} = {1} ]" -f $enumerator.Current.Key, $enumerator.Current.Value
}
}
$fileContent = @"
Foo = a
Bar = b
"@
$maliciousFileContent = @"
Foo = a
Bar = b
Count = 0
Keys =
Values =
"@
$hashtable = ConvertFrom-StringData $fileContent
$damagedHashtable = ConvertFrom-StringData $maliciousFileContent
Get-HashtableProperties $hashtable "Normal Hash Table"
Get-HashtableProperties $damagedHashtable "Damaged Hash Table"
输出:
---------- Normal Hash Table ----------
Count : 2
Keys.Count : 2
Values.Count : 2
Actual Count (Reflection) : 2
Items (Keys iteration):
[ Bar = b ]
[ Foo = a ]
Items (Enumerator iteration):
[ Bar = b ]
[ Foo = a ]
---------- Damaged Hash Table ----------
Count : 0
Keys.Count : 1
Values.Count : 1
Actual Count (Reflection) : 5
Items (Keys iteration):
[ = ]
Items (Enumerator iteration):
[ Count = 0 ]
[ Bar = b ]
[ Foo = a ]
[ Values = ]
[ Keys = ]
问题:有没有办法防止这个问题,除了在分配之前手动检查每个键和/或在我们需要访问某些Hashtable
属性的值时在代码中的任何地方使用反射?