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

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

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

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

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

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

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

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

Bean 属性的名称和值在填充任何 bean 之前都需要进行验证。Bean 填充功能允许开发人员设置 bean 属性或嵌套属性。攻击者可以利用此功能访问特殊的 bean 属性，例如 class.classLoader，此类属性将允许攻击者覆盖系统属性并可能会执行任意代码。

示例 1：以下代码在未正确验证属性名称或值的情况下设置用户控制的 bean 属性：

String prop = request.getParameter('prop');
String value = request.getParameter('value');
HashMap properties = new HashMap();
properties.put(prop, value);
BeanUtils.populate(user, properties);

基于 Touch ID 的身份验证有两种不同的实现方式：使用 LocalAuthentication 框架或使用密钥链服务中基于 Touch ID 的访问控制。

虽然这两者对于大多数应用程序而言都应当具有足够的强度，但 LocalAuthentication 方法所具备的一些特性使之不太适用于银行、医疗、保险等行业的高风险应用程序：

- LocalAuthentication 在设备的 Secure Enclave 之外定义，这意味着其 API 可以在已越狱的设备上进行挂钩和修改。
- LocalAuthentication 通过评估上下文策略来验证用户，该项评估的结果只能为 true 或 false。该布尔值评估意味着应用程序将无法知道实际得到验证的是谁，它只知道是否使用了已注册到设备的指纹。此外，可能以后注册的指纹也将成功地评估为 true。


示例 1：以下代码使用了 LocalAuthentication 框架执行用户身份验证：

    ...
    LAContext *context = [[LAContext alloc] init];  
    NSError *error = nil;  
    NSString *reason = @"Please authenticate using the Touch ID sensor.";
    
    if ([context canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&error]) {  
        [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
            localizedReason:reason
                reply:^(BOOL success, NSError *error) {
                    if (success) {
                        // Fingerprint was authenticated
                    } else {
                        // Fingerprint could not be authenticated
                    }
            }
        ];
    ...

基于 Touch ID 的身份验证可以使用密钥链服务实现，即在密钥链中存储项目，并设置一项访问控制来要求用户需在日后使用其指纹检索该项目。以下策略可用于定义如何使用其指纹对用户进行验证：

- kSecAccessControlUserPresence：限制为通过 Touch ID 或密码访问。不要求 Touch ID 可用或已注册。添加或删除指纹后，仍可通过 Touch ID 访问项目。
- kSecAccessControlTouchIDAny：限制为通过 Touch ID 使用任何已注册的指纹访问。添加或删除指纹后，项目不会失效。
- kSecAccessControlTouchIDCurrentSet：限制为通过 Touch ID 使用当前已注册的指纹访问。添加或删除指纹后，项目将会失效。

使用 Touch ID 时，应使用 kSecAccessControlTouchIDCurrentSet 属性阻止以后添加指纹或删除现有指纹。

示例 1：以下代码使用 kSecAccessControlTouchIDAny 限制，该项限制允许任何以后注册的指纹对密钥链项目解除锁定：

    ...
    SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
                 kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
                 kSecAccessControlTouchIDCurrentSet, 
                 nil);
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:account forKey:(__bridge id)kSecAttrAccount];
    [dict setObject:service forKey:(__bridge id) kSecAttrService];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:sacRef forKey:(__bridge id)kSecAttrAccessControl];
    [dict setObject:@"Please authenticate using the Touch ID sensor." forKey:(__bridge id)kSecUseOperationPrompt];

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        OSStatus status = SecItemAdd((__bridge CFDictionaryRef)dict, nil);
    });
    ...

根据 Apple 的政策，应用程序始终应向用户说明需要输入指纹的理由。如果未能做到这一点，可能会使用户感到困惑，甚至导致您的应用程序被 AppStore 拒绝。

示例 1：以下代码使用 Touch ID 验证用户，但未能提供正当理由来说明为何需要进行该验证：

    [context evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics localizedReason:nil
        reply:^(BOOL success, NSError *error) {
            if (success) {
                NSLog(@"Auth was OK");
            } 
    }];

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可以轻易地覆盖缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

Buffer overflow 漏洞通常出现在以下代码中：

— 依靠外部的数据来控制行为的代码。

— 受数据属性影响的代码，该数据在代码的临接范围之外执行。

— 代码过于复杂，以致于程序员无法准确预测它的行为。



以下例子分别演示了上面三种情况。

例 1.a：以下示例代码显示了简单的 buffer overflow，它通常由第一种情况所导致，即依靠外部数据来控制行为的代码。该代码使用 gets() 函数将一个任意大小的数据读取到堆栈缓冲区中。因为没有什么方法可以限制该函数读取数据的量，所以代码的安全性就依赖于用户始终输入比 BUFSIZE 少的字符数量。

	...
	char buf[BUFSIZE];
	gets(buf);
	...

例 1.b：这一例子表明模仿 C++ 中 gets() 函数的不安全行为是如此的简单，只要通过使用 >> 运算符将输入读取到 char[] 字符串中。

	...
	char buf[BUFSIZE];
	cin >> (buf);
	...

例 2：虽然本例中的代码也是依赖于用户输入来控制代码行为，但是它通过使用边界内存复制函数 memcpy() 增加了一个间接级。该函数接受一个目标缓冲区、一个起始缓冲区和要复制的字节数。虽然输入缓冲区由 read() 的边界调用填充，但是 memcpy() 复制的字节数需要由用户指定。

	...
char buf[64], in[MAX_SIZE];
printf("Enter buffer contents:\n");
read(0, in, MAX_SIZE-1);
printf("Bytes to copy:\n");
scanf("%d", &bytes);
memcpy(buf, in, bytes);
	...

注：该类型的 buffer overflow 漏洞（程序可读取数据，然后对剩余数据随后进行的内存操作中的一个数值给予信任）已在图像、音频和其他的文件处理库中频繁地出现。

例 3：这是一个关于第二种情况的例子，代码受未在本地校验的数据属性的影响。在本例中，名为 lccopy() 的函数将一个字符串作为其变量，然后返回一个堆分配字符串副本，并将该字符串的所有大写字母转化成了小写字母。因为该函数认为 str 总是比 BUFSIZE 小，所以它不会对输入执行任何边界检查。如果攻击者避开对调用 lccopy() 代码的检查，或者如果更改代码，使得程序员对 str 长度的原有假设与实际不符，那么 lccopy() 就会通过无边界调用 strcpy() 溢出 buf。

char *lccopy(const char *str) {
	char buf[BUFSIZE];
	char *p;

	strcpy(buf, str);
	for (p = buf; *p; p++) {
		if (isupper(*p)) {
			*p = tolower(*p);
		}
	}
	return strdup(buf);
}

示例 4：以下代码演示了第三种情况，代码非常复杂，无法轻松预测其行为。该代码来自通用的 libPNG 图像解码器，众多应用程序使用的都是该解码器。

该代码似乎可以安全地执行边界检查，因为它检测变量长度的大小，该变量长度会在之后用来控制 png_crc_read() 复制的数据量。然而，在测试长度前，该代码会立即对 png_ptr->mode 执行检查，如果检查失败，便会发出一个警告，然后会继续进行处理。因为 length 测试在 else if 块中进行，如果针对该代码的首次测试失败，那么就不会再测试 length，而将其盲目地用于调用 png_crc_read()，因此很容易引起堆栈 Buffer Overflow。

虽然本例中的代码不是我们所遇见的代码中最复杂的，但是它足以说明为什么要尽可能地降低执行内存操作代码的复杂度。

if (!(png_ptr->mode & PNG_HAVE_PLTE)) {
	/* Should be an error, but we can cope with it */
png_warning(png_ptr, "Missing PLTE before tRNS");
}
else if (length > (png_uint_32)png_ptr->num_palette) {
png_warning(png_ptr, "Incorrect tRNS chunk length");
png_crc_finish(png_ptr, length);
return;
}
...
png_crc_read(png_ptr, readbuf, (png_size_t)length);

例 5：本例同样演示了第三种情况，程序过于复杂，使其暴露出 buffer overflow 的问题。在这种情况下，问题出现的原因在于其中某个函数的接口不明确，而不是代码结构（同上一个例子中描述的情况一样）。

getUserInfo() 函数采用一个定义为多字节字符串的用户名和一个指向用户信息结构的指针，这一结构由该用户的相关信息填充。因为 Windows authentication 中的用户名使用 Unicode，所以 username 参数首先要从多字节字符串转换成 Unicode 字符串。然后，这个函数便会错误地将 unicodeUser 的长度以字节形式而不是字符形式传递出去。调用 MultiByteToWideChar() 可能会把 (UNLEN+1)*sizeof(WCHAR) 宽字符或者
(UNLEN+1)*sizeof(WCHAR)*sizeof(WCHAR) 字节，写到 unicodeUser 数组，该数组仅分配了 (UNLEN+1)*sizeof(WCHAR) 个字节。如果 username 字符串包含了多于 UNLEN 的字符，那么调用 MultiByteToWideChar() 将会溢出 unicodeUser 缓冲区。

void getUserInfo(char *username, struct _USER_INFO_2 info){
WCHAR unicodeUser[UNLEN+1];
	MultiByteToWideChar(CP_ACP, 0, username, -1,
    	      			unicodeUser, sizeof(unicodeUser));
NetUserGetInfo(NULL, unicodeUser, 2, (LPBYTE *)&info);
}

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

在这里，一个结构不良的 format string 会导致程序在分配的内存边界之外写入数据。

示例 1：以下代码会溢出 c，因为 double 类型需要的空间超过分配给 c 的空间。

void formatString(double d) {
    char c;

    scanf("%d", &c)
}

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

在这里，一个结构不良的 format string 会导致程序在分配的内存边界之外写入数据。

示例 1：以下 buf 会溢出 buf，因为根据 f 的大小，格式字符串说明符 "%d %.1f ... " 可能会超出分配的内存大小。

void formatString(int x, float f) {
   char buf[40];
   sprintf(buf, "%d %.1f ... ", x, f);
}

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的 off-by-one 错误在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆栈 buffer overflow 和堆 buffer overflow 等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

示例 1：以下代码包含一个 off-by-one 缓冲区溢出，当 recv 返回的字节数达到最大允许读取的 sizeof(buf) 字节数时，便会发生此溢出。在这种情况下，随后对 buf[nbytes] 的间接引用会将 null 字节写入到所分配内存的边界之外。

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}

Buffer overflow 可能是人们最熟悉的一种软件安全漏洞。虽然绝大多数软件开发者都知道什么是 Buffer overflow 漏洞，但是无论是对继承下来的或是新开发的应用程序来说，Buffer overflow 攻击仍然是一种最常见的攻击形式。对于这个问题出现的原因，一方面是造成 buffer overflow 漏洞的方式有很多种，另一方面是用于防止 buffer overflow 的技术也容易出错。

在一个典型的 buffer overflow 攻击中，攻击者将数据传送到某个程序，程序会将这些数据储存到一个较小的堆栈缓冲区内。结果，调用堆栈上的信息会被覆盖，其中包括函数的返回指针。数据会被用来设置返回指针的值，这样，当该函数返回时，函数的控制权便会转移给包含在攻击者数据中的恶意代码。

虽然这种类型的堆栈 buffer overflow 在某些平台和开发组织中十分常见，但仍不乏存在其他各种类型的 buffer overflow，其中包括堆 buffer overflow 和 off-by-one 错误等。有关 buffer overflow 如何进行攻击的详细信息，许多优秀的著作都进行了相关介绍，如 Building Secure Software [1]、Writing Secure Code [2] 以及 The Shellcoder's Handbook [3]。

在代码层上，buffer overflow 漏洞通常会违反程序员的各种假设。C 和 C++ 中的很多内存处理函数都没有执行边界检查，因而可轻易地超出缓冲区所操作的、已分配的边界。即使是边界函数（如 strncpy()），使用方式不正确也会引发漏洞。对内存的处理加之有关数据段大小和结构方面所存在种种错误假设，是导致大多数 buffer overflow 漏洞产生的根源。

示例 1：以下代码尝试通过检查从 getInputLength() 中读取的不可信的值，验证其是否小于目标缓冲区 output 的大小，来避免 off-by-one buffer overflow。然而，因为 len 和 MAX 之间比较的是带符号的值，所以如果 len 为负值，在其转换为 memcpy() 不带符号的参数时，将会变成一个超级大的正数。

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

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

即便 castor 创建了对象的锁定，也不能阻止其他线程对该对象执行读取或写入。另外，与默认的共享模式相比，只读模式的查询的运行速度大约是前者的 7 倍。

例 1：下例指定 SHARED 查询模式，该模式允许读取和写入访问。

results = query.execute(Database.SHARED);