不要事先在關鍵任務資源上使用可猜測的名稱
TL;DR：透過避免可預測的命名模式來保護您的雲端資源。
可預測的名字
未經授權的存取
資料暴露風險
影子資源
帳號接管
Idor 漏洞
過早優化
使用帶有暗鍵的唯一儲存桶名稱
驗證建立的所有權
充分保障資源
使用間接混淆真實姓名
書名防止搶註
隨機名稱
當攻擊者預見到雲端資源（例如 S3 儲存桶）的命名模式時，就會發生資源搶佔。
攻擊者在使用者尚未尚未部署資源的區域創建它們。
使用者與這些攻擊者擁有的資源的互動可能會導致嚴重的安全漏洞，例如資料外洩、未經授權的存取或帳戶接管。
此漏洞在 AWS 等經常使用可預測命名約定的環境中非常嚴重。
許多系統避免這種間接方式，擔心效能損失，這是過早最佳化的明顯例子。
def create_bucket(account_id, region):
bucket_name = f"aws-glue-assets-{account_id}-{region}"
create_s3_bucket(bucket_name)
# This is deterministic and open
import uuid
def create_bucket(account_id, region):
unique_id = uuid.uuid4().hex
# This number is not deterministic
# is a way to generate a random UUID (Universally Unique Identifier)
# in Python and then retrieve it as a hexadecimal string.
bucket_name = f"aws-glue-assets-{unique_id}-{account_id}-{region}"
create_s3_bucket(bucket_name)
verify_bucket_ownership(bucket_name, account_id)
[X] 自動
安全審核可以透過分析資源名稱的可預測性來檢測這種氣味。
尋找攻擊者可以輕鬆預測或猜測的名稱模式。
許多自動化工具和手動程式碼審查可以幫助識別這些風險。
[X] 中級
人工智慧生成器可以使用具有可預測命名模式的標準模板來創建這種氣味。
始終自訂和檢查產生的程式碼以確保安全。
如果配置了識別可預測或不安全資源命名約定的規則，人工智慧可以幫助檢測這種氣味。
這是一個安全風險，需要了解雲端基礎架構和潛在的攻擊媒介。
避免可預測的命名模式對於保護雲端資源至關重要。
始終使用獨特、晦澀、難以猜測的名稱，並驗證資源所有權以防止搶注攻擊。
GB 駭客
維基百科
程式碼味道是我的觀點。
照片由 Felix Koutchinski 在 Unsplash 上拍攝
唯一真正安全的系統是關閉並拔掉插頭的系統，鎖在鈦襯裡的保險箱中，埋在混凝土掩體中，周圍是神經毒氣和高薪武裝警衛。即便如此，我也不會賭上自己的人生。
吉恩‧斯帕福德
本文是 CodeSmell 系列的一部分。
以上是代碼氣味 - 蹲著的詳細內容。更多資訊請關注PHP中文網其他相關文章！
