常见缺陷列表

硬编码凭据通常会创建一个重要漏洞，使攻击者能够绕过产品管理员配置的身份验证。系统管理员可能很难检测到这个漏洞。即使检测到，也很难修复，因此管理员可能会被迫完全禁用产品。主要有两种变化：

在Inbound变体中，将创建一个默认的管理帐户，并将一个简单的密码硬编码到产品中并与该帐户关联。此硬编码密码对于产品的每个安装都是相同的，如果不手动修改程序或修补产品，系统管理员通常无法更改或禁用此密码。如果发现或发布了密码（这在互联网上很常见），那么任何知道该密码的人都可以访问该产品。最后，由于产品的所有安装都将使用相同的密码，即使在不同的组织中，也会发生蠕虫等大规模攻击。

Outbound变体适用于通过后端服务进行身份验证的前端系统。后端服务可能需要一个容易发现的固定密码。程序员可以简单地将这些后端凭证硬编码到前端产品中。该程序的任何用户都可以提取密码。带有硬编码密码的客户端系统构成了更大的威胁，因为从二进制文件中提取密码通常非常简单。

此列表显示了可能出现特定弱点的领域。这些可能是特定命名语言、操作系统、架构、范例、技术或此类平台的一类。列出了平台以及该实例出现给定弱点的频率。

语言文字

技术

示例1

以下代码使用硬编码密码连接到数据库：

这是连接客户端上的外部硬编码密码的示例。此代码将成功运行，但任何有权访问它的人都可以访问密码。程序发布后，除非程序打了补丁，否则数据库用户“scott”不会返回密码为“tiger”的数据库。有权访问此信息的狡猾员工可以利用此信息闯入系统。更糟糕的是，如果攻击者能够访问应用程序的字节码，他们可以使用javap-c命令访问反汇编的代码，其中包含使用的密码值。对于上面的示例，此操作的结果可能如下所示：

示例2

以下代码是后端内部硬编码密码的示例：

此程序的每个实例都可以使用相同的密码进入诊断模式。更糟糕的是，如果这个程序是以只包含二进制代码的发行版发布的，那么很难更改密码或禁用这个“功能”

示例3

以下代码示例尝试使用硬编码加密密钥验证密码。

加密密钥位于与密码进行比较的硬编码字符串值中。攻击者很可能会读取密钥并危害系统。

示例4

以下示例显示了Java和ASP的部分属性和配置文件。NET应用程序。这些文件包括用户名和密码信息，但它们存储在明文中。

这个Java示例显示了一个带有明文用户名/密码对的属性文件。

以下示例显示ASP的配置文件的一部分。网络应用程序。此配置文件包含数据库连接的用户名和密码信息，但这对信息以明文形式存储。

用户名和密码信息不应包含在配置文件或明文形式的属性文件中，因为这将允许任何可以读取文件的人访问资源。如果可能，请加密此信息。

示例5

2022年，OT:ICEFALL研究考察了10家不同运营技术（OT）供应商的产品。研究人员报告了56个漏洞，并表示这些产品“设计上不安全”[参考-1283]. 如果受到攻击，这些漏洞通常允许对手更改产品的操作方式，从拒绝服务到更改产品执行的代码。由于这些产品经常用于电力、电力、水和其他行业，因此甚至可能存在安全隐患。

多家供应商在其OT产品中使用了硬编码凭证。