在 .NET 中，您可以使用 BinaryFormatter 类将对象转换为二进制流，该二进制流包含对象本身以及反序列化期间重建对象所需的元数据。

使用 BinaryFormatter 类可能导致不安全的反序列化场景，即攻击者可以执行任意代码，滥用应用程序逻辑，或触发拒绝服务条件。

使用 BinaryFormatter 类型有风险，不建议用于数据处理，因为它不能保证安全。

示例 1：应用程序通过在 runtimeConfig.json 文件中将配置属性 EnableUnsafeBinaryFormatterSerialization 设置为 true，允许使用不安全的 BinaryFormatter 类。

...
AppContext.SetSwitch("System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization", true);
...

AccessibleObject API 允许程序员绕过由 Java 访问说明符提供的 access control 检查。特别是它让程序员能够允许反映对象绕过 Java access control，并反过来更改私有字段或调用私有方法、行为，这些通常情况下都是不允许的。

在常规 JSF 应用程序中，使用 UI 组件指定的转换器和验证器来转换和验证值。提交页面时会自动进行转换和验证。Fusion 应用程序中可创建书签的视图不会执行页面提交，因此默认情况下不会执行类似的转换或验证。

示例 1：以下配置文件代码段显示了配置为不执行 paramName URL 参数的转换或验证的可创建书签的示例视图。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

不建议开发人员使用未记录或隐藏的 API 构建其应用程序。 由于无法保证 Google 未来不会删除或更改这些 API，因此应避免使用它们，并且使用此类方法或字段具有破坏应用程序的较高风险。

在 Camera 对象释放后，代码试图使用该对象。在未重新获取 Camera 对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码使用切换按钮来打开和关闭照相机预览。用户轻按该按钮后，照相机预览停止，并释放照相机资源。但是，如果再按一次该按钮，将调用之前释放的 Camera 对象中的 startPreview()。

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

在媒体对象释放后，代码试图使用该对象。在未重新获取媒体对象的情况下任何对该资源的进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码使用暂停按钮来切换媒体播放。用户轻按该按钮后，当前歌曲或视频就会暂停，并将释放照相机资源。但是，如果再按一次该按钮，将调用之前释放的媒体资源中的 start()。

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

当 Android SQLite 数据库处理器关闭后，代码仍试图使用它。在未重新建立数据库连接的情况下，对处理器的任何进一步引用都将抛出异常。如果未捕获该异常，可能会导致应用程序崩溃。

示例 1：以下代码可能来自将用户值暂时缓存在内存中、但可调用 flushUpdates() 将这些变化提交到磁盘中的程序。该方法会在将更新写入数据库后正确关闭数据库处理器。然而，当再次调用 flushUpdates() 时，数据库对象会在重新初始化之前被再次引用。

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

Android 类加载劫持漏洞主要表现为以下两种形式：

- 攻击者可以更改程序在其中搜索来加载类的目录的名称，从而指向他们有控制权的某个目录的路径：攻击者明确控制了将在其中搜索类的路径。

- 攻击者可以更改用于加载类的环境：攻击者间接控制了路径名的含义。

在这种情况下，我们着重关注第一种情况，即攻击者有可能控制在其中搜索加载类的目录。这种类型的 Android Class Loading Hijacking 漏洞会在以下情况下出现：

1. 数据从不可信赖的数据源进入应用程序。



2. 数据用作一个或部分字符串，代表在其中搜索要加载的类的库目录。



3. 通过从库路径执行代码，应用程序授予攻击者在一般情况下无法获得的权限或能力。

例 1：以下代码使用用户可更改的 userClassPath，来确定在其中搜索要加载的类的目录。

...
  productCategory = this.getIntent().getExtras().getString("userClassPath");
  DexClassLoader dexClassLoader = new DexClassLoader(productCategory, optimizedDexOutputPath.getAbsolutePath(), null, getClassLoader());
  ...

此代码允许攻击者通过将 userClassPath 的结果修改为指向他们控制的不同路径，以提升的应用程序权限加载库并可能执行任意代码。因为程序不验证从环境读取的值，如果攻击者能够控制 userClassPath 的值，那么他们就可以欺骗应用程序指向他们控制的目录，从而使用与原始应用程序一样的权限加载他们已经定义的类。

例 2：以下代码使用用户可更改的 userOutput，来确定应将优化的 DEX 文件写入的目录。

...
  productCategory = this.getIntent().getExtras().getString("userOutput");
  DexClassLoader dexClassLoader = new DexClassLoader(sanitizedPath, productCategory, null, getClassLoader());
...

此代码允许攻击者指定优化的 DEX 文件 (ODEX) 的输出目录。这样，恶意用户便可以将 userOutput 的值更改为他们控制的目录，例如外部存储。一旦达到这一目的，便可以很轻松地将输出的 ODEX 文件替换为恶意 ODEX 文件，并使用与原始应用程序一样的权限加以执行。

当恶意行为者可以在给定 Zip 文件中指定 Zip 文件条目名称时，就会出现 Zip Path Traversal 漏洞。当恶意指定 Zip 文件条目名称时，攻击者可以在展开相应的 Zip 文件时覆盖关键系统文件的内容。攻击者可能会使用路径遍历习惯用法（例如 ../ 和 /）访问超出程序范围的系统文件。如果在 Zip 文件提取过程中检测到诸如 ../ 和 / 之类的习惯用法，针对 Android 14 及更高版本的 Android 应用程序默认情况下会抛出异常。此安全功能可能被覆盖或完全禁用。

示例 1：以下代码禁用 Zip Entry Overwrite 保护。

...
dalvik.system.ZipPathValidator.clearCallback();
...

压缩版本的库通过减少文件大小，改善了包含 JavaScript 文件的应用程序的页面加载时间。压缩指删除不必要的空白、注释、分号、括号、缩短本地变量的名称以及删除无法访问的代码的过程。

例 1：下列 ASPX 代码包含 Microsoft jQuery 库的未压缩版本：

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

在 ASP.NET Web API 服务中，未经验证的输入是导致漏洞产生的首要原因之一。未经检验的输入会导致出现各种漏洞，包括 Cross-Site Scripting、Process Control、Access Control 和 SQL Injection。尽管 ASP.NET Web API 服务通常情况下不容易受到 Memory Corruption 攻击，但是如果 ASP.NET Web API 服务调用未执行数组边界检查的本地代码，攻击者就可能会利用 ASP.NET Web API 服务中的 Input Validation 缺陷发起 Buffer Overflow 攻击。

为了防止此类攻击，请执行以下操作：
1. 使用验证属性通过编程将模型绑定对象参数的参数或成员的验证检查注释为 ASP.NET Web API 服务操作。
2. 使用 ModelState.IsValid 检查模型是否通过验证。

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);

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);
   }
   ...
}

模板引擎用于使用动态数据呈现内容。此上下文数据通常由用户控制并通过模板设置格式，以生成 Web 页面、电子邮件等。模板引擎可通过条件、循环等代码构造处理上下文数据，从而允许在模板中使用功能强大的语言表达式来呈现动态内容。如果攻击者能够控制要呈现的模板，他们将能够通过注入表达式来公开上下文数据，并在服务器中运行恶意代码。

示例 1：以下示例显示了如何通过 URL 检索模板并使用模板在 AngularJS 中呈现信息。

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

在这种情况下，$stateParams.expression将采用可能受用户控制的数据，并将其作为用于指定上下文的模板进行计算。这又可能会允许恶意用户在浏览器中运行他们想要的代码、检索关于代码运行的上下文的信息、查找有关如何创建应用程序的额外信息，或将此代码转换为 full blown XSS 攻击。

对布尔值执行算术运算可能与对整型值执行运算的操作方式不同，这可能会导致意外的结果。

在将字节数组的数据转换为 String 后，没有说明适用字符集外的数据会发生何种变化。这会导致数据丢失，或者在需要二进制数据来确保执行正确的安全措施时，安全级别降低。

示例 1：以下代码将数据转换为字符串，以便创建散列值。

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

如果文件的大小小于 BUFSIZE，只要 myFile 中的信息已编码为与默认字符集相同，此方式就会很有用。但是，如果使用不同的编码方式，或者为二进制文件，则信息将会丢失。进而导致生成的 SHA 散列值的可靠性降低，并且也将更容易产生冲突，在默认字符集外的数据由相同的值（如问号）表示时，尤其如此。