编码员征服了安全基础设施即代码系列。密码的纯文本存储
当谈到在你自己的组织中部署安全的基础设施即代码时,你做得怎么样?这可能是一个学习曲线,但学习绳索将是一个很好的机会来提高你的技能,在你的同行中脱颖而出,并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前,我想邀请你玩一个敏感数据存储漏洞的游戏化挑战;现在就玩,从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的?如果你的知识需要一些努力,请继续阅读。
如今,大多数计算机安全的关键涉及密码。即使采用了其他安全方法,如双因素认证或生物识别技术,大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说,密码是唯一使用的。
我们如此频繁地使用密码,以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击,甚至是胡乱猜测。当然,有些人仍然使用薄弱的密码,NordPass最近的一份报告就证明了这一点。很难相信,在2020年,人们仍然在使用12345以及其他一堆可猜测的单词,如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码,但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则,密码需要至少八个字符,由大写和小写字母组成,至少需要一个数字和一个特殊字符。
糟糕的是,即使用户遵守了制作最强种类的密码的规则,但如果这些密码都以明文形式存储,也可能没有任何好处。如果黑客能够读取整个密码文件,12345这个密码就和Nuts53!SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的?
以明文方式存储密码是不好的,因为它使系统和用户都处于危险之中。很明显,如果黑客能够找到并读取每一个用于访问系统的密码,那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户,并破坏整个系统或网站。而且,由于他们会使用适当的用户名和密码,内部安全可能不会发现入侵行为,或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户,因为很多人都会重复使用密码。因为我们让密码变得如此难以创建,所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件,他们几乎肯定会尝试使用相同的名字和密码访问其他系统,这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的,或者没有意识到这可能会在以后造成重大问题。例如,下面的代码是使用Terraform模板定义AWS资源时,用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,用于管理AWS中的MySQL数据库实例的密码是以明文存储的。这意味着任何有权限进入源代码库的人都可以阅读,甚至复制它。
保护密码因框架的不同而不同,但每个平台都存在保护方法。例如,MySQL密码可以存储在AWS Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,Terraform模板将从AWS Secrets Manager服务中获得密码,它将永远不会以明文形式存储在模板文件中。
通过避免明文存储来保护密码
密码是你的王国的钥匙,不应该以明文形式存储。即使是一个组织的内部人员也不应该访问一个大的、不受保护的密码库,这也不应该是一个公认的商业协议(现在有很多密码管理器允许加密的凭证共享--没有借口!)。还有一个危险是,恶意的内部人员会窥探文件,获得他们不应该获得的权限。
对于外部攻击,试想一下,如果通过像SQL注入漏洞这样简单的方法找到了进入你的数据库的后门,并且他们也获得了对存储密码的目录的访问权,这将是一个双重打击。你认为这有太多的错误步骤可以实现吗?可悲的是,这种情况正好发生在索尼2011年的漏洞中。超过一百万的客户密码是以明文形式存储的,Lulzsec黑客组织通过一个常见的SQL注入攻击进入了这些密码和更多的密码。
所有的密码都应该由支持框架中的任何防御措施来保护。对于Terraform来说,密码不应该被存储在模板文件中。建议使用AWS Secrets Manager或Azure Key Vault等安全存储,这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意,但你也需要在后端做你的工作。将密码从明文存储中分离出来,对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳;基本上,任何人都可以看到它们。当务之急是(尤其是在IaC环境中,突然有更多的人可以接触到敏感信息),对它们进行充分的散列,只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战,以保持你的所有网络安全技能得到磨练和更新。
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。


当谈到在你自己的组织中部署安全的基础设施即代码时,你做得怎么样?这可能是一个学习曲线,但学习绳索将是一个很好的机会来提高你的技能,在你的同行中脱颖而出,并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前,我想邀请你玩一个敏感数据存储漏洞的游戏化挑战;现在就玩,从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的?如果你的知识需要一些努力,请继续阅读。
如今,大多数计算机安全的关键涉及密码。即使采用了其他安全方法,如双因素认证或生物识别技术,大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说,密码是唯一使用的。
我们如此频繁地使用密码,以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击,甚至是胡乱猜测。当然,有些人仍然使用薄弱的密码,NordPass最近的一份报告就证明了这一点。很难相信,在2020年,人们仍然在使用12345以及其他一堆可猜测的单词,如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码,但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则,密码需要至少八个字符,由大写和小写字母组成,至少需要一个数字和一个特殊字符。
糟糕的是,即使用户遵守了制作最强种类的密码的规则,但如果这些密码都以明文形式存储,也可能没有任何好处。如果黑客能够读取整个密码文件,12345这个密码就和Nuts53!SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的?
以明文方式存储密码是不好的,因为它使系统和用户都处于危险之中。很明显,如果黑客能够找到并读取每一个用于访问系统的密码,那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户,并破坏整个系统或网站。而且,由于他们会使用适当的用户名和密码,内部安全可能不会发现入侵行为,或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户,因为很多人都会重复使用密码。因为我们让密码变得如此难以创建,所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件,他们几乎肯定会尝试使用相同的名字和密码访问其他系统,这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的,或者没有意识到这可能会在以后造成重大问题。例如,下面的代码是使用Terraform模板定义AWS资源时,用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,用于管理AWS中的MySQL数据库实例的密码是以明文存储的。这意味着任何有权限进入源代码库的人都可以阅读,甚至复制它。
保护密码因框架的不同而不同,但每个平台都存在保护方法。例如,MySQL密码可以存储在AWS Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,Terraform模板将从AWS Secrets Manager服务中获得密码,它将永远不会以明文形式存储在模板文件中。
通过避免明文存储来保护密码
密码是你的王国的钥匙,不应该以明文形式存储。即使是一个组织的内部人员也不应该访问一个大的、不受保护的密码库,这也不应该是一个公认的商业协议(现在有很多密码管理器允许加密的凭证共享--没有借口!)。还有一个危险是,恶意的内部人员会窥探文件,获得他们不应该获得的权限。
对于外部攻击,试想一下,如果通过像SQL注入漏洞这样简单的方法找到了进入你的数据库的后门,并且他们也获得了对存储密码的目录的访问权,这将是一个双重打击。你认为这有太多的错误步骤可以实现吗?可悲的是,这种情况正好发生在索尼2011年的漏洞中。超过一百万的客户密码是以明文形式存储的,Lulzsec黑客组织通过一个常见的SQL注入攻击进入了这些密码和更多的密码。
所有的密码都应该由支持框架中的任何防御措施来保护。对于Terraform来说,密码不应该被存储在模板文件中。建议使用AWS Secrets Manager或Azure Key Vault等安全存储,这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意,但你也需要在后端做你的工作。将密码从明文存储中分离出来,对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳;基本上,任何人都可以看到它们。当务之急是(尤其是在IaC环境中,突然有更多的人可以接触到敏感信息),对它们进行充分的散列,只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战,以保持你的所有网络安全技能得到磨练和更新。

当谈到在你自己的组织中部署安全的基础设施即代码时,你做得怎么样?这可能是一个学习曲线,但学习绳索将是一个很好的机会来提高你的技能,在你的同行中脱颖而出,并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前,我想邀请你玩一个敏感数据存储漏洞的游戏化挑战;现在就玩,从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的?如果你的知识需要一些努力,请继续阅读。
如今,大多数计算机安全的关键涉及密码。即使采用了其他安全方法,如双因素认证或生物识别技术,大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说,密码是唯一使用的。
我们如此频繁地使用密码,以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击,甚至是胡乱猜测。当然,有些人仍然使用薄弱的密码,NordPass最近的一份报告就证明了这一点。很难相信,在2020年,人们仍然在使用12345以及其他一堆可猜测的单词,如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码,但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则,密码需要至少八个字符,由大写和小写字母组成,至少需要一个数字和一个特殊字符。
糟糕的是,即使用户遵守了制作最强种类的密码的规则,但如果这些密码都以明文形式存储,也可能没有任何好处。如果黑客能够读取整个密码文件,12345这个密码就和Nuts53!SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的?
以明文方式存储密码是不好的,因为它使系统和用户都处于危险之中。很明显,如果黑客能够找到并读取每一个用于访问系统的密码,那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户,并破坏整个系统或网站。而且,由于他们会使用适当的用户名和密码,内部安全可能不会发现入侵行为,或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户,因为很多人都会重复使用密码。因为我们让密码变得如此难以创建,所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件,他们几乎肯定会尝试使用相同的名字和密码访问其他系统,这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的,或者没有意识到这可能会在以后造成重大问题。例如,下面的代码是使用Terraform模板定义AWS资源时,用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,用于管理AWS中的MySQL数据库实例的密码是以明文存储的。这意味着任何有权限进入源代码库的人都可以阅读,甚至复制它。
保护密码因框架的不同而不同,但每个平台都存在保护方法。例如,MySQL密码可以存储在AWS Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,Terraform模板将从AWS Secrets Manager服务中获得密码,它将永远不会以明文形式存储在模板文件中。
通过避免明文存储来保护密码
密码是你的王国的钥匙,不应该以明文形式存储。即使是一个组织的内部人员也不应该访问一个大的、不受保护的密码库,这也不应该是一个公认的商业协议(现在有很多密码管理器允许加密的凭证共享--没有借口!)。还有一个危险是,恶意的内部人员会窥探文件,获得他们不应该获得的权限。
对于外部攻击,试想一下,如果通过像SQL注入漏洞这样简单的方法找到了进入你的数据库的后门,并且他们也获得了对存储密码的目录的访问权,这将是一个双重打击。你认为这有太多的错误步骤可以实现吗?可悲的是,这种情况正好发生在索尼2011年的漏洞中。超过一百万的客户密码是以明文形式存储的,Lulzsec黑客组织通过一个常见的SQL注入攻击进入了这些密码和更多的密码。
所有的密码都应该由支持框架中的任何防御措施来保护。对于Terraform来说,密码不应该被存储在模板文件中。建议使用AWS Secrets Manager或Azure Key Vault等安全存储,这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意,但你也需要在后端做你的工作。将密码从明文存储中分离出来,对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳;基本上,任何人都可以看到它们。当务之急是(尤其是在IaC环境中,突然有更多的人可以接触到敏感信息),对它们进行充分的散列,只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战,以保持你的所有网络安全技能得到磨练和更新。

点击下面的链接,下载本资料的 PDF 文件。
Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
查看报告预定一个演示Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。
马蒂亚斯是一名研究员和开发人员,拥有超过15年的软件安全实践经验。他曾为Fortify Software和他自己的公司Sensei Security等公司开发解决方案。在他的职业生涯中,马蒂亚斯领导了多个应用安全研究项目,并将其转化为商业产品,他拥有超过10项专利。当他离开办公桌时,Matias曾担任高级应用安全培训courses ,并定期在全球会议上发言,包括RSA会议、黑帽、DefCon、BSIMM、OWASP AppSec和BruCon。
马蒂亚斯拥有根特大学的计算机工程博士学位,在那里他研究了通过程序混淆来隐藏应用程序的内部工作的应用安全。
当谈到在你自己的组织中部署安全的基础设施即代码时,你做得怎么样?这可能是一个学习曲线,但学习绳索将是一个很好的机会来提高你的技能,在你的同行中脱颖而出,并保持更多的最终用户数据安全。
在我们开始讨论我们最新的Coders Conquer Security系列的下一章之前,我想邀请你玩一个敏感数据存储漏洞的游戏化挑战;现在就玩,从Kubernetes、Terraform、Ansible、Docker或CloudFormation中选择。
那是怎样的?如果你的知识需要一些努力,请继续阅读。
如今,大多数计算机安全的关键涉及密码。即使采用了其他安全方法,如双因素认证或生物识别技术,大多数组织仍然采用基于密码的安全作为其保护的一个要素。对许多公司来说,密码是唯一使用的。
我们如此频繁地使用密码,以至于我们甚至有关于如何创建密码的规则。这应该是为了使他们不那么容易受到暴力攻击,甚至是胡乱猜测。当然,有些人仍然使用薄弱的密码,NordPass最近的一份报告就证明了这一点。很难相信,在2020年,人们仍然在使用12345以及其他一堆可猜测的单词,如巧克力、密码和上帝来保护他们最敏感的资产。
总有一些人不屑于使用强大的密码,但大多数专业机构会强迫用户以特定的方式制作他们的访问词或短语。我们现在都知道这些规则,密码需要至少八个字符,由大写和小写字母组成,至少需要一个数字和一个特殊字符。
糟糕的是,即使用户遵守了制作最强种类的密码的规则,但如果这些密码都以明文形式存储,也可能没有任何好处。如果黑客能够读取整个密码文件,12345这个密码就和Nuts53!SpiKe&Dog12一样糟糕。
为什么以明文方式存储密码是危险的?
以明文方式存储密码是不好的,因为它使系统和用户都处于危险之中。很明显,如果黑客能够找到并读取每一个用于访问系统的密码,那将是一场灾难。他们可以简单地找到一个拥有管理员证书的用户,并破坏整个系统或网站。而且,由于他们会使用适当的用户名和密码,内部安全可能不会发现入侵行为,或在损害发生后很久才发现。
让攻击者很容易窃取以明文存储的密码也会伤害到用户,因为很多人都会重复使用密码。因为我们让密码变得如此难以创建,所以很多人都会在多个网站上重复使用他们能够记住的密码。如果攻击者破坏了一个密码文件,他们几乎肯定会尝试使用相同的名字和密码访问其他系统,这使用户面临着二次犯罪的巨大风险。
不小心将密码存储在纯文本中是比较容易的,或者没有意识到这可能会在以后造成重大问题。例如,下面的代码是使用Terraform模板定义AWS资源时,用来存储密码的常见方法。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,用于管理AWS中的MySQL数据库实例的密码是以明文存储的。这意味着任何有权限进入源代码库的人都可以阅读,甚至复制它。
保护密码因框架的不同而不同,但每个平台都存在保护方法。例如,MySQL密码可以存储在AWS Secrets Manager这样的安全存储中。
资源 "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
在这个例子中,Terraform模板将从AWS Secrets Manager服务中获得密码,它将永远不会以明文形式存储在模板文件中。
通过避免明文存储来保护密码
密码是你的王国的钥匙,不应该以明文形式存储。即使是一个组织的内部人员也不应该访问一个大的、不受保护的密码库,这也不应该是一个公认的商业协议(现在有很多密码管理器允许加密的凭证共享--没有借口!)。还有一个危险是,恶意的内部人员会窥探文件,获得他们不应该获得的权限。
对于外部攻击,试想一下,如果通过像SQL注入漏洞这样简单的方法找到了进入你的数据库的后门,并且他们也获得了对存储密码的目录的访问权,这将是一个双重打击。你认为这有太多的错误步骤可以实现吗?可悲的是,这种情况正好发生在索尼2011年的漏洞中。超过一百万的客户密码是以明文形式存储的,Lulzsec黑客组织通过一个常见的SQL注入攻击进入了这些密码和更多的密码。
所有的密码都应该由支持框架中的任何防御措施来保护。对于Terraform来说,密码不应该被存储在模板文件中。建议使用AWS Secrets Manager或Azure Key Vault等安全存储,这取决于基础设施提供商。
迫使用户创建安全的密码是一个好主意,但你也需要在后端做你的工作。将密码从明文存储中分离出来,对保护你的用户和你的系统会有很大的帮助。明文密码存储的主要危险是访问控制不佳;基本上,任何人都可以看到它们。当务之急是(尤其是在IaC环境中,突然有更多的人可以接触到敏感信息),对它们进行充分的散列,只有那些绝对需要访问的人才能被授予访问权。
请查看 Secure Code Warrior博客页面,了解有关这一漏洞的更多见解,以及如何保护你的组织和你的客户免受其他安全缺陷和漏洞的蹂躏。你也可以在Secure Code Warrior 培训平台上尝试演示IaC挑战,以保持你的所有网络安全技能得到磨练和更新。
目录
Matias Madou, Ph.D.是一位安全专家、研究员和CTO,也是Secure Code Warrior 的联合创始人。Matias在根特大学获得了应用安全的博士学位,主要研究静态分析解决方案。后来他加入了美国的Fortify公司,在那里他意识到,仅仅检测代码问题而不帮助开发人员编写安全代码是不够的。这激发了他开发产品的热情,帮助开发人员,减轻安全的负担,并超越客户的期望。当他不在办公桌前作为Awesome团队的一员时,他喜欢站在舞台上,在包括RSA会议、BlackHat和DefCon等会议上发表演讲。

Secure Code Warrior 我们在这里为您的组织提供服务,帮助您在整个软件开发生命周期中确保代码安全,并创造一种将网络安全放在首位的文化。无论您是应用安全经理、开发人员、CISO或任何涉及安全的人,我们都可以帮助您的组织减少与不安全代码有关的风险。
预定一个演示下载资源
安全技能基准测试:简化企业安全设计
寻找有关 "按设计确保安全 "计划成功与否的有意义的数据是众所周知的难题。首席信息安全官(CISO)在试图证明投资回报率(ROI)和安全计划活动在人员和公司层面上的商业价值时,往往会面临挑战。更不用说,企业要深入了解自己的组织是如何以当前的行业标准为基准的,更是难上加难。美国总统的《国家网络安全战略》向利益相关者提出了 "通过设计实现安全和弹性 "的挑战。让 "按设计保证安全 "计划发挥作用的关键不仅在于为开发人员提供确保代码安全的技能,还在于向监管机构保证这些技能已经到位。在本演讲中,我们将分享大量定性和定量数据,这些数据来自多个主要来源,包括从超过 25 万名开发人员那里收集的内部数据点、数据驱动的客户洞察力以及公共研究。利用这些数据点的汇总,我们旨在传达一个跨多个垂直领域的 "按设计保证安全 "计划的现状。报告详细阐述了这一领域目前未得到充分利用的原因、成功的技能提升计划对降低网络安全风险的重大影响,以及消除代码库中各类漏洞的潜力。