不要提前在关键任务资源上使用可猜测的名称
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中文网其他相关文章!