弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

弱身份验证机制使组织面临未经授权的访问风险。

身份验证机制可能因各种原因而失败，例如：
- 弱密码
- 验证不当
- 弱凭据管理

Apache Ivy 自动化依赖项管理系统允许用户为依赖项指定版本状态（称为动态修订），而不是列出特定版本。如果攻击者能够危及依赖项存储库或诱骗编译系统从攻击者控制的存储库下载依赖项，那么编译系统可能只需提供动态修订说明符即可静默下载并运行受损的依赖项。除安全风险之外，动态修订还会引发代码质量风险：动态修订将软件安全性和稳定性控制权交到开发和发布软件所使用的依赖项的第三方的手中。

编译时，Ivy 连接存储库并尝试检索与列出的状态匹配的依赖项。

Ivy 接受以下动态修订说明符：

- latest.integration：选择最新修订版依赖项模块。
- latest.[any status]：选择至少为指定状态的最新修订版依赖项模块。例如，latest.milestone 将选择作为里程碑或发布版本的最新版本，latest.release 只会选择最新发布版本。
- 任何以 + 结尾的修订版本：选择最新子修订版依赖项模块。例如，如果修订版本 1.0.3、1.0.7 和 1.1.2 中存在依赖项，则指定为 1.0.+ 的修订版本将选择修订版本 1.0.7。
- 版本范围：范围的数学符号（例如 < 和 >）可用于匹配一系列版本。

示例 1：以下配置条目指示 Ivy 检索最新发布版 Clover 组件：

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

如果存储库受损，攻击者可以直接上传符合动态标准的版本，诱使 Ivy 下载恶意版本依赖项。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

开发人员在 Ant 目标中使用 <get> 任务指定外部依赖项，检索由相应 URL 指定的依赖项。此方法的功能等同于开发人员将各外部依赖项记录为软件项目附带的工件，但效果更加理想，因为它在执行编译时会自动检索及合并依赖项。

示例 1：Ant build.xml 配置文件中的以下代码摘录展示了典型的外部依赖项引用方法：

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会大大增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

在 Ivy 下，开发人员不会列出从中检索依赖项的显式 URL，而是指定依赖项名称和版本，Ivy 依赖其底层配置识别从中检索依赖项的服务器。对于常用组件，开发人员将不必研究依赖项位置。

示例 1：Ivy ivy.xml 文件中的以下代码摘录展示了开发人员如何使用依赖项名称和版本指定多个外部依赖项：

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。

可通过 Java 开发环境中的几个工具来帮助进行依赖项管理：Apache Ant 和 Apache Maven 编译系统都包含专门用来管理依赖项的功能，而 Apache Ivy 则是明确作为依赖项管理器而开发的。尽管这些工具在行为方式上存在差异，但它们都有一种通用的功能，即会自动下载在编译过程中指定的外部依赖项。这样一来，两个不同的开发人员用同一种方式来编译软件就容易得多。开发人员只需在编译文件中存储依赖项信息即可，这意味着，每个开发人员和编译工程师都可通过同一种方式来获得依赖项、编译代码并进行部署，而不需要手动进行繁琐的依赖项管理。以下示例演示了如何使用 Ivy、Ant 和 Maven 在编译过程中管理外部依赖项。

在 Maven 下，开发人员不会列出从中检索依赖项的显式 URL，而是指定依赖项名称和版本，Maven 依赖其底层配置识别从中检索依赖项的服务器。对于常用组件，开发人员将不必研究依赖项位置。

示例 1：Maven pom.xml 文件中的以下代码摘录展示了开发人员如何使用依赖项名称和版本指定多个外部依赖项：

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

以下两种不同类型的攻击场景会对这些系统产生影响：攻击者可能攻击托管依赖项的服务器，也可能攻击编译计算机用于将托管依赖项的服务器主机名的请求重定向到攻击者控制的计算机的 DNS 服务器。在这两种场景下，攻击者可将恶意版本依赖项注入基于未受攻击的计算机运行的编译系统中。

无论用于传递特洛伊木马依赖项的攻击向量如何，这些场景都有一个共同特点，即编译系统盲目接受恶意二进制代码并将其纳入编译系统。由于编译系统无法拒绝恶意二进制代码，且现有安全机制（例如，代码审查）通常侧重于内部开发的代码而非外部依赖项，此类攻击很可能会被忽视，因为它会通过开发环境扩展并可能投入生产环境。

尽管将受损依赖项引入手动编译过程存在一定风险，但自动编译系统倾向于每次在新环境中运行编译系统时从外部数据源检索依赖项，这会大大增加攻击者的攻击机会。攻击者只需在多次检索依赖项时选择一次攻击依赖项服务器或 DNS 服务器，以便攻击执行编译的计算机。

CakePHP 可配置为公开调试信息，如错误、警告、SQL 指令和堆栈跟踪信息。在生产环境中，不应使用 Debug Information。

例 1：

    Configure::write('debug', 3);

Configure::write() 方法的第二个参数表示调试级别。数值越大，记录的日志信息越冗长。

会话持续时间越长，攻击者危害用户帐户的机会就越大。当会话处于活动状态时，攻击者可能会强力攻击用户的密码、破解用户的无线加密密钥或者通过打开的浏览器强占会话。如果创建大量的会话，较长的会话超时时间还会阻止系统释放内存，并最终导致 denial of service。

例 1： 以下示例显示了配置有 low 会话安全级别的 CakePHP。

    Configure::write('Security.level', 'low');

Security.level 和 Session.timeout 设置共同定义会话的有效长度。实际会话超时时间等于 Session.timeout 乘以以下倍数之一：

'high' = x 10
'medium' = x 100
'low' = x 300

将明文证书存储在配置或清单文件中使得任何可以读取该文件的人都能够访问受证书保护的资源。开发人员有时认为他们无法保护应用程序免受有权访问配置的人的侵害，但这种态度使应用程序更容易受到攻击者的攻击。规范的证书管理准则要求绝不能采用明文形式存储证书。

攻击者可以通过 ClassLoader Manipulation 攻击访问和修改底层应用程序服务器设置。在某些应用程序服务器（例如，Tomcat 8）上，攻击者可能会调整这些设置，以上传 web shell 并执行任意命令。

DNS 欺骗（也称为 DNS 缓存中毒）是一种攻击类型，攻击者破坏 DNS 解析器的缓存，导致其返回错误的 IP 地址。利用 DNS 欺骗，攻击者可以在用户不知情的情况下将用户重定向到恶意网站。在使用 Node.js 的服务器端 JavaScript 环境中，DNS 服务器设置处理不当可能会导致安全漏洞。

示例 1：考虑这样一种情况： Node.js 应用程序允许用户指定自定义 DNS 服务器。如果未正确验证和清理此输入，攻击者可以提供恶意 DNS 服务器并实施 DNS 欺骗攻击。

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

在此示例中，customDnsServers 变量被赋予一个来自用户控制输入的值。然后此输入用于使用 dns.setServers(customDnsServers) 设置 DNS 服务器。如果攻击者提供恶意 DNS 服务器地址，他们可以指示应用程序使用他们的服务器解析域名，从而返回错误的 IP 地址。

当 Dockerfile 未指定 USER 时，Docker 容器默认以超级用户权限运行。这些超级用户权限会传播给容器内运行的代码，这些权限通常是不必要的。以超级用户权限运行 Docker 容器扩大了攻击面，这可能使攻击者能够执行更严重的漏洞利用。

Dockerfile 可以为依赖项和基础映像指定未绑定的版本范围。如果攻击者能够将恶意版本的依赖项添加到存储库中或诱骗编译系统从攻击者控制的存储库下载依赖项，如果 docker 没有配置特定版本的依赖项，则 docker 将静默下载并运行受损的依赖项。

攻击者可以利用这种缺陷实施供应链攻击，其中攻击者可以利用开发人员的错误配置、误植域名以及向开源存储库添加恶意程序包。这种类型的攻击利用对已发布程序包的信任来获取访问权限并窃取数据。

在 docker 中，latest 标签自动指示映像的版本级别，该映像不使用摘要或唯一标签提供其版本信息。Docker 的机制是自动指定 latest 标签指向最新的映像清单文件。由于标签是可变的，因此攻击者可以替换使用 latest（或弱标签，如 imagename-lst, imagename-last, myimage）的映像和层。

示例 1：以下配置指示 Docker 选择最新版本的 ubuntu 基础映像。

    FROM ubuntu:Latest
    ...

Docker 不会验证配置为支持程序包管理器的存储库是否值得信赖。

示例 2：以下配置指示程序包管理器 zypper 检索给定程序包的最新版本。

...
zypper install package
...

在Example 2 中，如果存储库遭到破坏，攻击者只需上传符合动态标准的版本并诱使 zypper 下载依赖项的恶意版本。

当 Dockerfile 的 USER 指令设置为 root 时，它将拥有在容器内进行更改的过度许可权限。这违反了以最低权限运行映像的原则。通常情况下，安装程序包和创建文件夹可能需要 root 权限。安装完成后，最好添加具有受限权限的用户。

默认情况下，Docker 允许将特权端口绑定到容器，如果用户未声明端口，则 Docker 会将容器端口映射到 49153-65535 范围内的某个端口。在很多情况下，运行服务需要打开某些端口，随着时间的推移，开放的端口数可能会越来越多。开放的端口会增加攻击面，特别是对于以更高权限运行的服务。确保只打开运行该特定服务所需的端口。当服务不要求较高的权限时，在特权端口范围以外的端口上运行这些服务。

您可以使用 docker inspect 和 history 命令从公开可用的 docker 映像重建 Dockerfile，或者通过使用第三方工具自动执行此过程来进行重建。如果使用 ADD/COPY 命令添加敏感信息，攻击者可以重新创建每个 docker 层来获取信息。

使用 Volumes 也可能会暴露敏感目录。如果需要使用 Volumes 持久化数据，请避免挂载敏感目录。

以下目录被视为敏感目录：

- /
- /boot
- /dev
- /etc
- /lib
- /proc
- /sys
- /usr

当 Secure Shell (SSH) 服务在容器内运行时，将很难管理访问策略、密钥、密码和安全升级。

当自主代理（例如 AI 模型或聊天机器人）被赋予执行任务、做出决策或执行命令的能力但没有足够的限制、验证或人工监督时，就会出现代理权过大的问题。这可能导致意想不到的后果，包括安全风险、数据泄露甚至恶意行为。
当代理拥有过多的自由时，它可能会无意中与关键系统交互、执行高风险操作或暴露敏感数据。当代理被允许执行诸如转账、修改系统配置或发送电子邮件等操作而无需获得授权用户的授权或批准时，可能会发生极严重的后果。

示例 1：AI 助手被赋予执行关键任务和与用户代理协调的能力，但由于缺乏严格的检查或对权限的限制，它可以自主地执行敏感指令：

    model_client = OpenAIChatCompletionClient(model="gpt-4")
    assistant = AssistantAgent("assistant", model_client=model_client)

    # Create the termination condition which ends the conversation when the user says "APPROVE".
    termination = TextMentionTermination("APPROVE")

    team = RoundRobinGroupChat([assistant], termination_condition=termination)

    # Run the conversation and stream to the console.
    stream = team.run_stream(task="Perform critical task.")

如果授予 AI 助手在最少监督下“执行关键任务”的自主权，AI 就可能在没有人工审查的情况下执行命令或操作数据。只有当用户明确提到“批准”时才会触发终止条件，否则代理可以继续运行，如果其行为没有得到充分监控或约束，则会带来风险。

使用 CDN 来提供应用程序所依赖的 JavaScript 与通过应用程序自身的服务器提供 JavaScript 相比有许多优势。其中包括提高了性能，以及减少了应用程序所有者的代码维护工作。但是，应用程序假定 CDN 会将安全内容发送至浏览器。如果攻击者攻击 CDN，CDN 会将恶意代码发送至用户浏览器。因此，用户的浏览器会执行应用程序无法控制或检测出有恶意的代码。

例 1：下列 ASPX 代码通过引用 Microsoft CDN 包含 Microsoft 的 jQuery 代码：

...
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js" type="text/javascript"></script>
...

例 2：下列 ASPX 代码会自动将所有 ASP.NET 框架脚本请求重定向至 Microsoft Ajax CDN：

...
<asp:ScriptManager
   ID="ScriptManager1"
   EnableCdn="true"
   Runat="Server" />
...

在Example 2 中，ScriptManager 控件会将其 ASPX 页面配置为自动将任何脚本请求重定向到相应的 CDN。

如果您使用 Blaze DS 来记录所有意外事件，services-config.xml 描述符文件会指定一个“Logging”XML 元素来描述日志记录的不同方面。它类似于以下内容：

示例 1：

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

此 target 标签可采用一个名为 level 的可选属性，用来指示日志级别。如果调试级别设置为太详细的级别，您的应用程序可能会将敏感数据写入日志文件。