密码学中使用加密和解密来隐藏原始信息。这为信息安全带来了保密性。

加密技术的目的是确保通过不安全渠道连接的两个人或设备之间的通信安全。

发送者通常使用加密密钥来加密信息，而接收者使用解密密钥来解密信息。

一般来说，密码学采用两种策略：

1. 对称密钥加密（私钥）： 这种技术，使用的加密密钥和解密密钥对于发送方、接收方都是已知的。使用这种方式的有一次性密码、Vernam密码、Playfair、行列密码和数据加密标准（DES）。

2. 非对称密钥加密（公钥）： 使用此技术，每个人都有两个密钥：私钥（保密，只有创建者才能使用）和公钥（任何人都可以自由使用）。发送方和接收方使用不同的密钥进行加密和解密。使用该技术的一些算法示例包括 Rivest–Shamir–Adleman算法（RSA）、Diffie–Hellman密钥交换（DHE）和数字签名算法（DSA）。

软件工程师通常必须通过服务器或GitHub等其他服务进行身份验证才能进行版本控制。

与使用密码身份验证相反，他们可以使用公钥身份验证在计算机上生成并存储一对加密密钥。然后，他们可以将运行在另一台计算机上的服务器配置为识别并接受这些密钥。

这是我们前面讨论的非对称密钥加密技术流程，它是一个更安全的身份验证过程。

在本教程中，你将了解这一切是如何工作的，SSH的含义，以及如何使用SSH keygen生成使用RSA算法的SSH密钥。

先决条件

• 在任何操作系统上运行的工作计算机
• 熟悉命令行的基本操作
• 面带微笑：）

SSH 简介（Secure Shell Protocol)

使用SSH的公钥身份验证是一种比密码更安全的登录服务方法。一旦你从上面的介绍中了解了密码学是如何工作的，那么理解SSH就更容易了。

以下是一个基本定义：

“Secure Shell协议是一种加密网络协议，用于在不安全的网络上安全地运行网络服务。”（来源）

SSH在客户端和服务器之间使用，两者都在SSH协议上运行，以远程登录到服务器并通过命令行访问某些资源。

SSH协议有一个开源版本（版本2），其中包含一套称为OpenSSH（也称为OpenBSD Secure Shell）的工具。此项目包括以下工具：

• 远程操作：ssh、scp 和 sftp.
• 密钥生成：ssh-add、ssh-keysign、ssh-keyscan 和 ssh-keygen
• 服务端：sshd、sftp-server 和 ssh-agent

如何为 RSA 登录生成 SSH 公钥

我们的目标是使用 ssh-keygen 使用 RSA 算法生成 SSH 公钥。这将创建一个密钥对，其中包含私钥（保存到本地计算机）和公钥（上传到所选服务）。

现在要继续，请按照以下步骤实现此目的：

如果你尚未安装OpenSSH，请使用以下命令安装OpenSSH：

// for mac

brew install openssh

// for linux

sudo apt install openssh-client && sudo apt install openssh-server

2. 使用以下命令使用 RSA 算法（默认为 2046 位加密）创建私钥/公钥对：

ssh-keygen -t rsa

3. 或者，如果要使用具有 4096 位加密的 RSA 算法进行创建，请使用以下命令：

ssh-keygen -t rsa -b 4096

4. 输入要将密钥保存到的文件位置（默认情况下，它将保存到你的用户目录（例如，(/Users/bolajiayodeji/.ssh/id_rsa)）。

5. 输入密码短语以提高私钥的安全性。通常，一个好的密码短语应至少包含 15 个字符（包括至少一个大写字母、小写字母、数字和特殊字符），并且必须难以猜测。你可以在线使用这些密码生成器之一，也可以使用十六进制转储轻松生成释义，如下所示：

hexdump -vn16 -e'4/4 "%08X" 1 "\n"' /dev/urandom

6. 成功创建密码后，你的私钥将保存在/<your_chosen_directory>/.ssh/id_rsa中，你的公钥将保存在/<your_chosen_directory>/.ssh/id_rsa.pub中。

现在，你可以使用ssh-copy-id（此工具是openSSH的一部分）将创建的密钥复制到要连接的服务器的authorized_keys文件中，如下所示：

ssh-copy-id username@remote_host

或者，你希望将 SSH 私钥添加到 ssh 代理中，并将密码存储在钥匙串中。然后，你可以通过仪表板 UI 等将 SHH 密钥添加到服务器的帐户中（例如，使用 Git 或 GitHub 等工具）。

结语

尽管强密码有助于防止暴力攻击，但公钥身份验证使用加密技术提供了更安全的身份验证过程。

希望这篇文章对你有所帮助。此外，你可以查看ssh-keygen手册页和以下资源以进行进一步学习：

• Connecting to GitHub with SSH
• Get started with OpenSSH for Windows

加油！💙

SQL 注入是指你通过客户端向应用程序输入数据来插入或注入一个 SQL 查询。

成功的攻击使攻击者能够访问数据库中的敏感数据，修改数据库数据，可能关闭数据库或发出其他管理员命令，恢复文件内容，以及偶尔向操作系统发出命令。

这种类型的攻击相对容易检测和利用，因此迅速修复任何易受攻击的系统尤为重要。

SQL 注入如何工作

当数据从不可信任的来源进入程序，并被用于动态构建 SQL 查询时，就会发生 SQL 注入。

因为 SQL 无法区分控制平面和数据平面，攻击者可以在数据输入中插入元字符（一种不被解释为数据的字符，例如下划线 _，在 SQL 中，它会被解释为单个字符的通配符），然后在控制平面中输入 SQL 命令。

例如，在下面的漫画中，如果字符串 Robert'); DROP TABLE Students;–- 被输入到一个请求 studentName 的查询中，那么查询将变为以下内容：

AND studentName = 'Robert';
DROP TABLE Students;
--'

DROP TABLE 命令用于删除一个表及其所有行数据，而一对连字符（hyphens）告诉大多数数据库服务器，该语句的剩余部分应被视为注释（这使得服务器可以忽略修改后的查询中留下的尾部）。

https://xkcd.com/327/

许多数据库服务器允许一次执行多个查询，只要它们用分号隔开。如果允许这样做，这种攻击类型就允许攻击者对数据库执行多个命令（有些数据库服务器，包括 Oracle，不允许这种执行方式）。

防止 SQL 注入实际上相当简单 - 要么不允许动态查询，要么阻止包含恶意 SQL 的用户输入影响查询逻辑。

其他类型的 SQL 注入

还有一些其他类型的 SQL 注入需要注意：

基于错误的 SQL 注入

攻击者依赖于数据库的详细错误信息来了解数据库结构。为了防止这种情况，只应显示通用错误信息。

盲注 SQL 注入

当应用程序容易受到 SQL 注入攻击时，但只显示通用错误信息（而不是详细的错误信息或查询结果）。

一种访问信息的方法是使用 true/false 查询并一次提取一个问题的信息。另一种选择是发送一个命令，要求数据库在返回响应之前等待特定的时间。

根据数据库返回错误信息所需的时间长短，攻击者可以推断命令是返回 true 还是 false。

UNION SQL 注入

利用 UNION 操作符从数据库中的多个表中检索数据。

带外 SQL 注入

相对罕见，但当攻击者无法在提交命令的同一通道中接收到响应时会发生。

相反，它依赖于服务器使用另一种协议（如 HTTP 或 DNS）来向攻击者的查询传递响应的能力。

如何防止 SQL 注入攻击

预处理语句（带参数化查询）

参数化查询要求开发者定义所有 SQL 代码并稍后将每个参数传递给查询。然后，数据库可以区分代码和数据，而不受用户输入的影响。

例如，如果攻击者输入名字 Robert'); DROP TABLE Students;–- ，参数化查询将不再容易受到攻击，而是寻找一个与整个字符串 Robert'); DROP TABLE Students;–- 完全匹配的名字。

预处理语句的优点是 SQL 代码保留在应用程序内，使其（大部分）独立于数据库。

在极少数情况下，这可能会影响性能。如果确实如此，开发者需要验证所有数据，或者使用针对数据库的转义程序转义所有用户提供的输入。

存储过程

存储过程是带参数的预创建 SQL 语句，不包括任何动态 SQL 生成（可以做，但不应该做）。为了设置存储过程，开发者需要为所需的输入构建带参数的 SQL 语句。

存储过程和预处理语句之间的区别在于，存储过程是在数据库中定义和存储的，但是从应用程序中调用的。

此外，由于存储过程在某些 DBMS 中需要执行权限（默认情况下不可用），因此创建一个具有最少权限的单独帐户而不是授予所有者访问权限非常重要。

白名单输入验证

白名单输入验证将外部输入与一组已知的、批准的输入进行比较，对于不匹配的输入将失败。这只应用于不允许绑定变量的情况（SQL 语句中实际值的占位符）。

白名单输入验证还可以作为在将输入传递给查询之前检测输入的备选方案。

转义所有用户提供的输入

只有在前面的选项不可行时，才应使用此方法，因为它无法防止所有 SQL 注入。仅对无法重写以使用前面推荐方法的遗留代码使用它。遗憾的是，这是一个非常针对特定数据库的实现。

每个 DBMS 都支持字符转义方案。如果使用正确的方案转义所有用户输入，DBMS 将能够区分输入和开发者编写的 SQL 代码。

最小权限

最小权限不是防御 SQL 注入的手段，而是一种限制任何攻击可能造成的损害的方法。

确保应用程序帐户只拥有所需的权限，而不是更多，可能会令人沮丧（给予它们 DBA 或管理员权限肯定更容易，但会提供更多的攻击面）。

与其剥夺帐户的访问权限，不如从头开始，只授予确切需要的访问权限。

例如，如果一个帐户只需要只读访问权限，请确保它只对所需的表（甚至是表的一部分）具有只读访问权限。如果可以的话，避免授予数据库帐户创建或删除访问权限。每个用户/应用程序应该有一个单独的帐户。

此外，审查数据库管理系统（DBMS）运行所在的操作系统帐户的权限。默认情况下，许多帐户具有非常强大的权限 - 将其更改为更合适的权限。

来源/进一步阅读

• OWASP SQL Injection
• PortSwigger SQL Injection
• Netsparker SQL Injection

SSL 和 TLS 协议经常受到攻击。了解过去的攻击可以为你作为防御者的知识提供参考，并帮助你保护当前的系统。它还可以帮助你预测未来攻击的方向。

因此，这里总结了一些针对这些协议的最有名的攻击。

针对 SSL/TLS 的浏览器漏洞（BEAST）

BEAST（2011 年披露）允许中间人攻击者从 SSL/TLS 会话中发现加密的信息。它影响了 SSL 3.0 和 TLS 1.0。

这种攻击取决于 TLS 使用的区块密码的实现。该实现使用 CBC，即密码块链模式。这包括将每个明文块（除了第一个）与前一个密码块进行 XOR，然后对该块使用加密算法。

第一个区块与一个 IV（初始化向量）进行 XOR。该模式的大部分安全性取决于 IV 是真正随机的。但 TLS 1.0 并没有随机生成 IV--它只是使用前一个信息的最后一个密码文本块。这意味着，任何能够窥探加密通信的人都有一份 IV 的副本。

可以窥探加密通信的攻击者可以通过猜测一个数据块，将其与（已知）IV 和前一个密码文本块进行 XOR，并将创建的数据块注入会话，从而发起选择明文攻击。这使得攻击者可以检查整个数据块是否正确。

鉴于此，在 BEAST 发布之前，这个缺陷在很大程度上被认为是理论上的。BEAST 找到了一种方法来转移密码块的边界，每次隔离一个字节的信息，直到它被猜中。

这一点，加上 HTTP 消息通常是标准化的，所以攻击者会知道敏感信息（如会话 cookie）在消息中的传输位置，允许攻击者用暴力破坏会话 cookie。

虽然这种攻击在理论上非常有趣，并引起了很多人的兴趣，但它只有在攻击者能够在页面中插入恶意代码并违反同源策略的情况下才有效。如果攻击者对你的系统有这么多的访问权，他们也会有许多可以尝试的攻击，其中许多执行起来要复杂得多。

针对 SSL/TLS 攻击的缓解措施

1. （最安全）只允许 TLS 1.1 或 1.2，因为它们解决了这个漏洞。然而，在当时，大多数网站和浏览器都不支持 TLS 1.1.或 1.2。
2. 由于 TLS 同时支持区块密码和流密码，因此改用流密码（RC4）。然而，在 2013 年证明 RC4 是不安全的，在 2015 年它被正式禁止（由互联网工程任务组，或 IETF）。
3. 使用不同的区块密码模式。不幸的是，TLS 1.0 并不支持任何其他模式。
4. 基本上，由于长度为 0 的数据包将被填充到块的大小，它对发送方来说只是一个填充的数据包，但会被接收方立即丢弃。这些块将被用作下一个消息的 IV，解决了不安全的 IV 问题。这个选项在很大程度上没有被使用，因为它导致了与一些 SSL 堆栈的互操作性问题，特别是包括 Internet Explorer 6.0。OpenSSL 实现了这一点，但默认情况下禁用了它。
5. 实行纵深防御，以防止攻击者获得对受害者网络的中间人访问。

来源/更多信息

• BEAST 攻击是如何工作的
• BEAST 攻击的图解指南
• BEAST 的原创文章
• 对 BEAST、CRIME、TIME、BREACH、LUCKY 13 和 RC4 Biases 的综合研究

Heartbleed 漏洞

Heartbleed（2012 年引入/2014 年 4 月披露）是 OpenSSL 库的 heartbeat 扩展中的一个漏洞（这是用来保持连接打开）。

这个库主要用于运行 Apache 和 NGINX 的服务器（在披露时，大约 17%的互联网 "安全"（使用 SSL/TLS）网站存在漏洞），但影响到任何依赖有漏洞的 OpenSSL 版本的服务器。

基本上，客户端向服务器发送一个消息，其中包含它所要求的响应和响应的大小。服务器会以所要求的大小响应所要求的数据（见下面 xkcd 的解释）。

漏洞是服务器不会检查请求是否真的与它的声明大小相同。如果用户发送的请求响应（例如 "鸟"）比要求的长度（500 个字母）短，服务器就会用内存中的数据 "填充 "响应，以满足长度要求，可能会泄露敏感的内存信息。

https://xkcd.com/1354/

这些泄漏的数据将是未加密的，可能包含任何东西--敏感的证书、文件等等。

但是，为了成功地利用这个漏洞，需要发生几件事：网站必须实施 SSL，需要运行有漏洞的 OpenSSL 版本（有漏洞的版本在 1.0.1 和 1.0.1f 之间），攻击者需要在发现漏洞存在和它被修补之间有机会进入环境，并且在攻击者进行攻击时，内存中需要有一些有用的东西。这相对来说更加困难，尽管远非不可能。

不幸的是，由于该漏洞在日志中没有留下任何异常的痕迹，所以很难知道这个漏洞是否真的被利用了，或者有多频繁。

此外，这还没有考虑到攻击者有以前的 pcaps 流量，并在攻击中提取网站的私钥的危险。这意味着他们可能已经解密了大量的敏感数据，造成严重的漏洞。

如果情报机构能够完成这种类型的攻击，它很可能永远不会被公开发布。

缓解 Heartbleed 漏洞的措施

• 将 OpenSSL 升级到最新版本，修补漏洞（有漏洞的版本在 1.0.1 和 1.0.1f 之间）。

来源/更多信息

• 5 年后，Heartbleed 漏洞仍未得到修补
• XKCD Heartbleed
• 你需要知道的关于 "Heartbleed" 的一切信息

填充 Oracle 导致传统加密降级（POODLE）

POODLE（2014 年 9 月披露）利用了 SSL3.0 的一个缺陷。为了支持传统系统，一些系统继续提供对 SSL3.0 的支持，尽管它已经被更新的版本所取代。

为了使攻击成功，攻击者需要能够控制 SSL 连接的客户端的部分内容，并需要对所产生的密码文本有可见性（拥有这种权限的最常见方法是充当中间人）。

这种攻击虽然强大，但确实需要单独的攻击来获得这种权限。

在一个典型的握手协商中，客户和服务器将一起工作，以找到一个适合双方通信的协议。他们会从双方都提供的最高协议开始，然后往下进行（因此客户可能提供 TLS 1.2，而服务器可能回应 TLS 1.1）。

但如果连接失败（无论是由于攻击者还是网络连接问题），客户服务器将降级到他们提供的最低协议，可能是 SSL 3.0。这是一个提供的 "功能"，以便处于不同发展阶段的服务器和客户端可以进行通信。

SSL3.0 使用 RC4（流密码）或 CBC 模式的块密码进行加密。RC4 是众所周知的，即使在当时，也有一些缺陷，包括如果重复发送相同的秘密（如 cookie），越来越多的信息会泄漏。

CBC 模式要求消息的长度是区块大小的倍数，或者使用填充物来满足长度条件。这意味着填充物经常被使用，而在 SSL 3.0 的实现中，并没有验证它在传输过程中是否有变化。

从本质上讲，虽然在发送前和接收端对信息进行了哈希处理，并对重新编译的哈希进行比较以确保信息的完整性，但不包括填充。

对填充的唯一规定是，最后一个字节需要是填充的长度。因此，攻击者可以替换填充物，只要他们的最后一个数字正确，仍然会被接受。

如果攻击者知道他们试图解密的数据的位置（例如 HTTP 会话 cookie，它通常每次都是在区块的相同部分发送，因此很容易找到），他们可以把它复制到最后的区块，替换掉填充。

然后，接收器将把填充的块与前一个块的密码文本（攻击者可以看到）进行 XOR，只有在最后一个字节与填充的长度相匹配时才会接受数据。

从本质上讲，这种攻击使暴力破解 SSL 成为可能。而在没有任何信息的情况下，几乎不可能对 SSL 进行暴力破解，这种攻击允许在每个字节最多尝试 256 次后恢复每个字节。这意味着，在几分钟内，攻击者可以破坏一个会话 cookie 或其他敏感信息。

POODLE 的缓解措施

• 禁用 SSL 3.0 是唯一完全缓解 POODLE 的方法。然而，有些网站只支持 SSL 3.0。
• 一个替代方案是使用 TLS_FALLBACK_SCV 密码套件。这个套件允许服务器回落到早期的协议，但不是立即下降到 SSL 3.0，客户可以指定一个偏好。这个套件的一个问题是，它在推出时并没有得到广泛支持（主要限于谷歌服务）。此外，如果服务器支持的唯一选项是 SSL 3.0，POODLE 攻击仍然是可能的。然而，这意味着攻击者无法在与支持其他协议的服务器的连接上强制降级。
• 实行纵深防御，以防止攻击者获得对受害者网络的中间人访问。虽然这种攻击很危险，但它需要中间人访问，这使得它比可远程利用的 Heartbleed 更难被利用。

来源/更多信息

• 你需要知道的关于 POODLE 漏洞的一切
• POODLE 攻击: 利用 SSL 3.0 的回退功能
• 什么是 POODLE 攻击?
• CISA SSL 3.0 协议漏洞

结束语

了解过去对 TLS 和 SSL 的攻击，既可以为你作为防御者提供知识，也可以帮助你保护你的系统。

通常情况下，系统是过时的，或者传统的应用程序可能需要使用过时的协议。这意味着，如果不适当地应用防御措施，甚至旧的攻击也可能成功。

在许多情况下，从事企业安全工作需要有足够的信息来做出明智的决定和建议。例如，如果一个传统的应用程序需要使用一个过时的协议，那么像 POODLE 和 Heartbleed 这样的攻击知识可以帮助你对如何保护该应用程序提出有效的建议，而不是提出像“更新到一个更新的协议”这样的一般性建议（这可能在实际中做不了）。

通常情况下，作为一个安全分析师，你要努力平衡业务需求和技术能力，并根据组织的风险水平提出建议。这可能意味着说，一个传统的应用程序不应该再运行了，也可能意味着鉴于它需要使用一个不安全的协议，就如何尽可能地保证应用程序的安全运行而提出建议。

了解过去的 TLS/SSL 攻击也可以帮助你预测未来攻击的方向。自 Heartbleed 和 POODLE（2014 年）以来，我们已经看到了像 2015 年的 FREAK 和 Logjam 以及 2016 年的 Sweet32 的攻击。我们可能会继续看到更多的攻击。

了解 TLS 和 SSL 工作的基本原理，以及它们在过去是如何被攻击的，可以帮助你预测或了解未来的攻击。

封面照片："cybersecurity"，作者：Christian Colen

当写到内存的内容超过分配给它的大小时，就会发生缓冲区溢出。这种行为可能会导致数据损坏、程序崩溃，甚至是恶意代码的执行。

C、C++和Objective-C是容易出现缓冲区溢出漏洞的主要语言（因为它们比许多解释型语言更直接地处理内存），然而它们很大程度上奠定了互联网发展的基础。

即使代码是用"安全"语言（如Python）编写的，如果它调用任何用C、C++或Objective C编写的库，它仍然有可能受到缓冲区溢出的影响。

内存分配

为了理解缓冲区溢出，我们有必要了解一下程序如何分配内存。在C语言中，你可以在编译时在堆栈中分配内存，也可以在运行时在堆中分配内存。

在堆栈上声明一个变量：int numberPoints = 10;

或者在堆上声明变量：int* ptr = malloc (10 * sizeof(int));

缓冲区溢出可以发生在栈（栈溢出）或堆上（堆溢出）。

一般来说，栈溢出比堆溢出更常被利用。这是因为栈包含一连串的嵌套函数，每个函数都返回调用函数的地址，在函数运行结束后，栈应该返回该地址。这个返回地址可以被替换为执行一段恶意代码的指令。

由于堆较少存储这些返回地址，因此更难发起攻击（尽管不是不可能）。堆上的内存通常包含程序数据，并且是在程序运行时动态分配的。这意味着堆溢出很可能要覆盖一个函数指针--比栈溢出更难也更不有效。

由于栈溢出是更常被利用的缓冲区溢出类型，我们将简要地挖掘它们的具体工作原理。

栈溢出

当一个可执行文件被运行时，它在一个进程中运行，每个进程都有自己的栈。当进程执行主函数时，它将发现并创建新的局部变量（这些变量将被推到堆栈的顶部）和对其他函数的调用（这些函数将创建一个新的栈帧）。

为了更清楚的展示，请参考下图：

https://en.wikipedia.org/wiki/Stack_(abstract_data_type)

那么，什么是栈帧？

首先，调用栈基本上是一个特定程序的汇编代码。它是一个由变量和栈帧组成的栈，它告诉计算机以什么顺序执行指令。每个尚未完成执行的函数都会有一个栈帧，当前正在执行的函数在堆栈顶部。

为了持续的追踪栈帧，计算机在内存中保留了以下几个指针：

• 栈指针： 指向进程调用栈的顶部（或压入栈的最后一个指针）。
• 指令指针： 指向下一条要执行的CPU指令的地址。
• 基准指针（BP）：（也称为帧指针）指向当前栈帧的基点。只要程序在执行当前栈帧，它就保持不变（尽管栈指针会改变）。

例如，请看以下程序：

int main() {
    int j = firstFunction(5);
    return 0;
}
    
int firstFunction(int z) {
    int x = 1 + z;
    return x;
}

在调用 firstFunction 和执行语句int x = 1+z之后，调用栈会是这样的：

这里，main调用了firstFunction（目前正在执行），所以它在调用栈的顶部。返回地址是调用它的函数的内存地址（这是在创建栈帧时由指令指针持有）。仍在范围内的局部变量也在调用栈上。当它们被执行并超出范围时，它们会从栈顶部被“弹出”。

因此，计算机能够跟踪哪条指令需要被执行，判断以何种顺序执行。栈溢出是为了用攻击者自己设计的恶意地址覆盖这些保存的返回地址之一。

缓冲区溢出漏洞实例（C）：

int main() {
    bufferOverflow();
 }
 
 bufferOverflow() {
    char textLine[10];
    printf("Enter your line of text: ");
    gets(textLine);
    printf("You entered: ", textLine);
    return 0;
 }

这个简单的例子读入了任意数量的数据（gets会读入到文件的末尾或换行符）。想一想我们上面看过的调栈，你就会明白为什么这很危险。如果用户输入的数据多于变量被分配的数量，用户输入的字符串将覆盖调用栈的下一个内存位置。如果它足够长，它甚至可能覆盖调用函数的返回地址。

计算机对此的反应取决于栈的实现方式和特定系统中内存的分配方式。对缓冲区溢出的反应是不可预测的，从程序故障，到崩溃，再到执行恶意代码。

为什么会发生缓冲区溢出?

缓冲区溢出之所以成为如此重大的问题，是因为C和C++中的许多内存操作函数不执行任何边界检查。缓冲区溢出现在相当有名，它们也非常普遍地被利用（例如，WannaCry 利用了缓冲区溢出）。

缓冲区溢出最常见的情况是，代码依赖于外部输入数据，这种方式过于复杂，程序员不容易理解其行为，或者它有代码直接范围之外的依赖关系。

网络服务器、应用服务器和网络应用环境都容易受到缓冲区溢出的影响。

用解释型语言编写的环境是个例外，尽管解释者本身也容易受到溢出的影响。

如何减轻缓冲区溢出的影响

• 使用解释性的语言 这并不容易受缓冲区溢出的影响。
• 避免使用不进行缓冲区检查的函数（例如，在C语言中，用 fgets() 代替 gets()。）
• 使用能够帮助识别不安全函数或错误的编译器。
• 使用金丝雀， 这是一种 "防护值"，可以帮助防止缓冲区溢出。它们被插入到堆栈中的返回地址之前，并在返回地址被访问之前被检查。如果程序检测到金丝雀值的变化，它将中止进程，防止攻击者得逞。警戒值要么是随机的（所以，攻击者很难猜到），要么是一串字符，由于技术原因，不可能被覆盖。
• 重新安排局部变量 所以普通变量（单个固定大小的数据对象）高于数组变量（包含多个值）。这意味着，如果数组变量真的溢出，它们不会影响普通变量。这种技术，当与警戒值相结合时，它可以帮助抵御缓冲区溢出攻击。
• 将一个栈变为不可执行 通过设置NX（No-eXecute）位，防止攻击者将shellcode直接插入栈中并在那里执行它。这并不是一个完美的解决方案，因为即使是不可执行的栈也会成为缓冲区溢出攻击的受害者，如返回到libc攻击。当栈框架的返回地址被替换成已经在进程地址空间的库的地址时，这种攻击就会发生。此外，并非所有的CPU都允许设置NX位。
• ASLR（地址空间布局随机化），它可以作为一种一般的防御措施（以及对返回到libc攻击的特殊防御）。这意味着，无论何时一个库文件或其他函数被运行中的进程调用，其地址都会被一个随机数移位。这使得几乎不可能将一个固定的进程内存地址与函数联系起来，这意味着攻击者很难，甚至不可能知道从哪里调用特定的函数。在许多版本的Linux、OS X和Android中，ASLR是默认开启的（可以在命令行中切换关闭）。

关于Stack Underflow的说明：

当同一个程序的两个部分以不同的方式处理同一个内存块时，也有可能出现缓冲区溢出的漏洞。例如，如果你分配了一个大小为X的数组，但用大小为x<X的数组填充它，后来你试图检索所有X字节，你很可能得到X-x字节的垃圾数据。

从本质上讲，你可能已经拉出了一些数据，这些数据是以前使用该内存时留下的。最好的情况是，它是没有任何意义的垃圾，而最坏的情况是，它是攻击者可能会滥用的敏感数据。

资料来源/进一步的阅读：

• Computer and Network Security Lectures, Avinash Kak
• OWASP Buffer Overflows
• Stack vs Heap

有一天，我正在工作中处理一个功能。我在 JIRA 工单（tickets）中创建了很多分支，所以我想在不同的标签页中一次性打开一堆 PRs（Pull Requests）。

这是我通常的工作方式——我有很多标签打开，这可以加快工作速度，因为我不需要等待下一个页面的加载。

但是当我在 BitBucket 中创建了第一个 PR，并试图进入下一个页面时，我收到了一条错误信息，说是一个无效的 CSRF 令牌（token）。这是面对 CSRF，保护 Web 应用程序的一个常见问题。

所以在这篇文章中，你将了解什么是 CSRF 以及如何修复这个错误。

目录

• 什么是 CSRF?
• CSRF 防护的标准
• 使用口令的问题
• 交叉标签通信解决方案
  • Sysend 库
  • 广播频道
• 总结

什么是 CSRF?

CSRF 是跨站请求伪造（Cross-Site Request Forgery） 的首字母缩写。它通常是攻击者用来进入你的系统的一种攻击媒介。

你通常防止 CSRF 的方法是发送一个由每个 HTTP 请求产生的唯一的令牌（token）。如果服务器上的令牌与请求中的令牌不匹配，你会向用户显示一个错误。

CSRF 防护的标准

这是你用令牌对抗 CSRF 的一种方法：

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER]
        });
        return response;
    };
})(inital_token);

这段代码使用 fetch API 来发送和接收 HTTP 报头中的安全令牌。在后端，你应该在页面加载时生成第一个初始令牌。在服务器上，在每个 AJAX请求中，你应该检查该令牌是否有效。

使用口令的问题

上述方法很有用，但是如果你打开一个以上的标签，它就有问题了。每个标签都可以向服务器发送请求，这将破坏这个解决方案。而高级用户可能无法以他们想要的方式使用你的应用程序。

但这个问题有一个简单的解决方案，即跨标签通信。

交叉标签通信解决方案

Sysend 库

你可以使用 Sysend 库，这是一个开源的解决方案，我专门为此目的而创建。它简化了跨标签的通信。

如果你愿意，你可以使用像 广播频道 这样的本地浏览器 API 来做同样的事情。在本文后面会有更多关于如何做到这一点的介绍。

但 Sysend 库对不支持 Broadcast Channel（广播频道）的浏览器也有作用。它也可以在 IE 中工作（它有一些错误，这并不奇怪）。你可能还需要支持一些旧的移动浏览器。它还有一个更简单的 API。

这是最简单的例子：

let token;
sysend.on('token', new_token => {
    token = new_token;
});

// ...

sysend.broadcast('token', token);

使用 sysend 库的基本功能的简单例子

而这就是你如何使用这个库来修复 CSRF 保护：

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const EVENT_NAME = 'csrf';
    sysend.on(EVENT_NAME, new_token => {
        // get new toke from different tab
        token = new_token;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new toke to other tabs
           sysend.broadcast(EVENT_NAME, token); 
        });
        return response;
    };
})(inital_token);

使用 sysend 的带有 CSRF 保护的 secure_fetch 函数

你所要做的就是在发送请求时从其他标签页发送和接收一条信息。而你的 CSRF 保护的应用程序将在许多标签页上工作。

就这样了。这将让高级用户在想打开许多标签页时使用你的有 CSRF 保护的应用程序。

广播频道

下面是使用广播频道的最简单例子：

const channel = new BroadcastChannel('my-connection');
channel.addEventListener('message', (e) => {
    console.log(e.data); // 'some message'
});
channel.postMessage('some message');

广播频道的基本用法

因此，通过这个简单的 API，你可以做和上面一样的事情：

const inital_token = '...';

const secure_fetch = (token => {
    const CSRF_HEADER = 'X-CSRF-TOKEN';
    const channel = new BroadcastChannel('csrf-protection');
    channel.addEventListener('message', (e) => {
        // get new toke from different tab
     token = e.data;
    });
    return (url) => {
        const response = await fetch(url, {
            method: 'POST',
            headers: {
              [CSRF_HEADER]: token
            }
        });
        response.then(res => {
           token = res.headers[CSRF_HEADER];
           // send new token to other tabs
           channel.postMessage(token);
        });
        return response;
    };
})(inital_token);

使用广播频道的带有 CSRF 保护的 secure_fetch 函数

正如你在上面的例子中看到的，广播频道没有任何事件命名空间。因此，如果你想发送多于一种类型的事件，你需要创建事件类型。

下面是一个使用广播频道的例子，除了我们到目前为止讨论的 CSRF 保护修复之外，还可以做更多的事情。

你可以为你的应用程序同步登录和注销。如果你登录到一个标签，你也会登录到其他标签。以同样的方式，你可以同步一些电子商务网站的购物车。

const channel = new BroadcastChannel('my-connection');
const CSRF = 'app/csrf';
const LOGIN = 'app/login';
const LOGOUT = 'app/logout';
let token;
channel.addEventListener('message', (e) => {
    switch (e.data.type) {
        case CSRF:
            token = e.data.payload;
            break;
        case LOGIN:
            const { user } = e.data.payload;
            autologin(user);
            break;
        case LOGOUT:
            logout();
            break;
    }
});

channel.postMessage({type: 'login', payload: { user } });

使用具有不同类型信息的广播频道

总结

如果你保护你的应用免受攻击，那就太好了。 但是请想清楚人们将如何使用你的应用程序，避免不必要的东西，导致难以使用。这不仅适用于这个特定问题。

Sysend 库是一种在同一浏览器中打开的选项卡之间进行通信的简单方法。 它可以解决 CSRF 保护的主要问题。 该库具有更多功能，你可以查看其 GitHub repo 了解更多详细信息。

广播频道也没有那么复杂。 如果你不需要支持旧的浏览器或一些旧的移动设备，你可以使用这个 API。 但是如果你需要支持旧的浏览器，或者想让你的代码更简单，你可以使用 sysend 库。

如果你想查看浏览器对广播频道的支持，可以查看 Can I Use 网站。

杰克-斯科菲尔德是一位多产的记者，为《卫报》撰稿，接近40年。在此期间，他写了三篇特别的文章，被称为 "斯科菲尔德的计算法则".

杰克并不是一下子就创造了这些原则，而是在他整个职业生涯中遇到的发现的积累。

单独来看，这些原则并不特别，也不是革命性的--事实上，它们是非常基本的。然而，它们是你应该坚持的宝贵经验，特别是在团体组织中。

斯科菲尔德第一法则

“除非你能清楚看到如何把数据弄出来，否则千万不要把数据放进程序。” ― 杰克-斯科菲尔德 (2003)

斯科菲尔德的第一法则指出，当你依赖一个组织时，你应该确认将你的数据转移到另一个组织会很容易。

你想要更换供应商常见原因可能是。

• 服务条款的改变。
• 另一家具有不同愿景的公司接手。
• 涨价或转变为一个不太有利的商业模式。
• 服务关闭，或软件成为废弃软件。

例如:

• LastPass将免费用户限制在一种类型的设备上。(更多信息)
• ArtStation被Epic Games收购。(更多信息)
• Adobe转向软件即服务的商业模式(SaaS)。(更多信息)
• Megaupload被关闭并被管理机构查封。(更多信息)

数据可移植性是软件和服务的一个基本特征。当你需要避免供应商的锁定或必须为迁移过程做昂贵的预算时，这是主要的解决方案。

什么是供应商锁定？

供应商锁定是指公司将用户绑在他们的软件上。用户可以在迁移到公司竞争对手的软件时采取一些措施来增加摩擦（难度）。

其目的是通过使离开的步骤不方便、费时或繁琐，即使用户有更好的选择，也能迫使用户留下。

当你选择要使用的软件或服务时，你要注意这种做法。这可以有多种形式。

• 不允许你导出个人数据或用户生成的内容。
• 不允许将文件导出为开放或人可读的格式。
• 使软件与现有的开放标准不兼容。

数据可迁移的权利

通用数据保护条例 (GDPR)有助于提高数据可迁移的权利。它促使像Discord、Instagram和Twitter这样的公司为用户添加自动化工具来导出他们的内容。

GDPR的第20条是 "数据可迁移性权利"，即有办法将你的个人数据从数据控制者那里转移到你可以给另一个数据控制者的标准格式的权利。

尽管GDPR是专门针对个人数据的，但这已经促进了通用的数据可迁移性，包括用户生成的内容。虽然在欧盟之外执行GDPR的难度值得商榷，但这些工具通常也可以让其他司法管辖区(欧盟外)的成员使用。

如果你代表一个组织或自由职业者，负责挑选软件，请记住这一点！

斯科菲尔德第二法则

"数据不真正存在，除非你至少有两个副本(起码有三份)。"
― 杰克-斯科菲尔德 (2008)

备份数据是大多数人拖延的一个苦差事，直到它太晚(发生损毁)。但幸运的是，事实证明，organizations（组织）在这方面更成熟一些。

斯科菲尔德的第二法则表明，除非你至少有两份数据的副本，否则你应该把它当作不存在的东西。

理想情况下，你应该将这两份副本保存在不同的物理位置--我指的不是不同的驱动器，而是不同国家或大陆。

对于你拥有的数据，如你的台式机、笔记本电脑或闪存驱动器。

• 设备或你的整个库存可能丢失或被盗。
• 如果你有全盘加密，你可能忘记你的密码。
• 你的硬件可能在你身上发生故障，导致数据丢失。
• 火灾或水灾等灾难可能会破坏一切。

这甚至可能是由于用户的错误造成的。不管你的技术水平如何，你可能会用 "覆盖 "而不是 "另存为"，将操作系统刷入到错误的驱动器上，或者一个开发人员在修改提交后强行推送到错误的分支。

你应该时刻准备好应对可能导致数据丢失的情况。虽然不是每个人都有足够的可支配的收入，但设备一般很容易用足够的钱来购买，但可能多年积累的数据是无法从设备中恢复的。

云端的数据

斯科菲尔德第二法则 不仅针对你拥有的数据，还包括你保存在云端的数据。例如，你应该把你的云存储、电子邮件和媒体内容也存放在第二个地方。

当使用那些不需要备份你的数据，或在一段时间不活动后关闭你的账户的服务时，这一点尤其重要。这在那些提供真正免费服务的公司中很常见，它们不需要成本，也不需要跟踪，比如Nextcloud供应商或Tutanota。

不要因为你的数据在云中就认为它是安全的。最近的一个例子是OVH的一个数据中心发生火灾，导致数据丢失。OVH公共云提供非管理型服务器，这意味着用户负责管理和备份他们的服务器。(更多信息)

此外，还存在着漏洞的风险，允许未经授权的人访问你的账户。

例如，去年黑客获得了对Twitter管理工具的访问权，使他们能够访问许多知名的账户。使用这样的工具，要删除以前的帖子和媒体也是很容易的。(更多信息)

同步你的数据

你可以通过使用在你的电脑和服务器之间同步数据的解决方案来解决其中的一些问题。这提供了保护，防止任何与硬件有关的故障，或物理损坏。

如果数据丢失会有不利的后果，应该加密并同步到云存储。一些软件，如Bitwarden或Thunderbird，本身也依赖于同步，所以即使服务器消失了，你的设备上仍然有一个最新的副本。

然而，同步并不能解决所有问题--最理想的是也有一个独立的备份。同步将自动发送所有的变化，包括用户错误，甚至是恶意软件或勒索软件所做的修改。有定期的冷存储备份对这样的情况会很方便。

斯科菲尔德第三法则

"你越容易访问你的数据，其他人就越容易访问你的数据。" ― 杰克-斯科菲尔德 (2008)

保护数据一直涉及到在安全性和便利性之间找到一个平衡点。我们希望数据对我们来说容易访问，但对其他人来说很难访问。

这种冲突导致了关于数据疏忽的问题。

当你把数据放在云端时，这会自动使它更容易被他人访问。你的云供应商可能有漏洞，有人可能会猜到你的密码，或者一个云供应商员工可能会违背公司原则，破坏或出售你的数据。

你可能会责怪某人或获得赔偿，但你的数据和可能是你客户的数据仍然在那里，而你会是最终允许它发生的人。

提高安全性往往有些不方便，但是别人在企图破坏账户时正是利用了这种不方便：

• 暴力破解 – 猜短密码，因为它破解得更快。
• 伪造凭证 – 押注于密码的重复使用，因为这让密码使用者比管理多个密码更方便。
• 字典攻击 – 猜常用密码，因为它对于密码使用者更容易回忆。

此外，这些攻击基于用户没有启用2FA，以及另一方的数据没有被混淆或加密。

你或你的组织应该使用一个密码管理器，在所有系统上执行2FA，并在可能的情况下，在数据被发送到第三方服务器之前进行加密。

甚至更好，删除不再相关的数据(无用的数据)。删除数据总是比担心保护数据要好。

这可能包括聊天记录、电子邮件或包含机密信息的文件、社交媒体密码，以及客户或员工数据。特别是如果它们是几个月或几年前的，不再有意义。如果你不需要它们，其他人也不需要。

总结

这些法则是在10多年前确立的，今天比以往任何时候都更适用。

技术和开放标准已经发生了演变，所以它们更容易被遵守。但随着云计算基础设施的发展，我们越来越信任第三方来处理我们的数据。在许多情况下，我们可能对它被留在哪里以及谁能接触到它感到太舒服(太信任)了。

不幸的是，杰克-斯科菲尔德于2020年3月去世，但他支持了科技界的许多人。我希望通过分享他的经验，其他人可以继续从中学习。

原文：Schofield's Laws of Computing – What they Are and Why You Should Know Them，作者：Seth Falco

加密是一个双向的功能-也就是说，你能消除任何对信息进行扰乱。

今天，有两种基本类型的基本算法-对此和非对称。

对此算法也被称为secret key(秘钥) 算法，而非对称算法则被称为public key(公钥)算法。

两者的关键区别在于，对称算法使用相同的密钥进行加密和解密，而非对称算法使用不同的密钥进行加密和解密。

关于密码学的一般概述以及对称和非对称密码的区别，请查看本文.

当你开发一个密码时，哪些原则时重要的？

克尔克霍夫原则指出，一个加密系统应该是安全的，即使所有的细节(key除外)都是公开的。克劳德-香农后来将这一说成 敌人知道系统。

从本质上讲，一个设计得非常好得系统应该能够发送加密信息，即使攻击者能使用相同得算法(用不同得密钥)加密和解密自己的消息。加密信息的安全性应该完全取决于密钥。

此外，为了阻碍统计分析(试图破解加密算法)，一个好的密码系统应该采用混乱和扩散的原则。

混乱要求密钥不能以简单的方式与加密后产生的文本相关联性。加密后产生的文本的每个字符都应取决于密钥的多个部分。其目的是使攻击者很难从加密后产生的文本中确定密钥。

扩散的意思是，如果明文中的一个字符被改变，那么加密后产生的文本中几个字符也应该改变。如果加密后产生的文本中一个字符改变，那么明文中的几个字符也应该改变。

理想情况下，加密后产生的文本和明文之间的关系是隐藏的。没有任何扩散是完美的(都会有一些模式)，但最好的扩散是将模式广泛扩散，甚至是几个模式一起使用。

扩散使攻击者难以发现模式，并要求攻击者拥有更多的数据，以发起成功的攻击。

如果你想多读一点这方面的内容，可以查看密码学的数学理论.

什么是块和流加密(Stream Ciphers)？

块和流加密都是对称密钥密码(如DES、RCx、Blowfish和Rijndael AES)。块加密将明文逐块转换为密文，而流加密则每次转换为一个字节。

大多数现代对称算法都是block ciphers(块加密)，尽管块大小不同(如EDS(64位)，AES(128,192和256位)，等等)。

流加密的优势是什么？

流加密的速度更快(时间上是线性的)，在空间上是恒定的。它不太可能发生传输错误，因为一个字节的转换错误不会影响下一个字节。

当明文的数量未知时(如音频或视频流)，或者极端的性能要求下(如非常高速的连接，或者需要非常有效的和紧凑的设备，如智能卡)，你通常会使用流加密。

流加密的工作原理是由密钥生成一系列的伪随机字节(对于给定的密钥，加密和解密过程中的使用相同的伪随机字节)。不同的密钥会产生不同的字节串。

为了加密数据，明文字节与伪随机字节串进行XOR(异或操作)。为了解密，将加密后产生的文本与相同的伪随机字节串进行XOR(异或操作)，就可以看到明文。

块加密的优势是什么？

块加密有很高的扩散性(一个明文符合被扩散到几个密码文本符号中)。攻击者要插入符号而不被发现是很困难的，因为他们不可能轻易将符号插入到块的中间。

然而，它比流加密慢(加密/解密之前需要传输整个块)，如果发生错误，它可以传染到这个块，破坏整个块。

当你知道传输数据规模时，块加密是一个更好的选择，例如在传输文件。

块加密的常见模式是什么？

为了对多块的数据进行加密，有几种模式已经被开发出来。这些模块将单块原则用于更长的消息。

块加密有5种保密模式。其中一些模式需要一个初始化向量(IV) 才能发挥作用。

什么是Initialization Vector (IV 初始化变量)?

IV的本质只是用于创建密文的另一个输入(除了明文和密钥)。它是一个数据块，被几种模式的块加密用来随机化加密，这样即使相同的明文被重复加密，也会产生不同的密文。

它通常不是秘密，尽管它不会被重复使用。在理想情况下，它应该是随机的，不可预测和一次性使用。

两个相同的信息用相同的密钥加密，但不同的IV，将导致不同的密文。 这使进行攻击更加困难。

Electronic Code Book Mode (ECB 电子代码本模式)

在明文的输入块和密文输出块有一个固定的映射(基本上就像一个实际的密码本，密文的字与明文直接相关)。

ECD对每个明文块应用加密函数进行加密(对每个密文块应用逆向函数进行解密)。这意味着CBC可以并行地加密和解密多个块(因为它们相互不依赖)，加快了处理进程。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

要使这种模式正常工作，要么信息长度是块大小的整数倍，要么你需要使用填充来满足长度条件。

填充实质上为了满足块大小而添加的额外数据。在这种模式下，给定相同的密钥，相同的明文块将总是导致相同的密文块。这是它很容易受到攻击，所以这种模式很少使用(应该避免使用)。

Cipher Block Chaining Mode (CBC 加密块链模式)

这种加密模式将新的明文块与前一个加密区关联(chains)或者结合起来，这需要为第一个块提供一个IV。IV不需要加密，但它要不可预测。

CBC将第一个明文块与IV密文块进行XOR(异或)，以创建第一个密文块。使用ECB模式将IV作为一个短消息单独发送。

然后，CBD对该块使用加密算法，产生第一个密文块。然后，CBC将此密文块与第一个文明块进行XOR(异或)，并应用加密算法产生第二个密文块，如果反复，直到消息的最后。

为了解密，CBC做了想法的工作--第一个密文块使用反向的加密算法，然后将该块与IV进行XOR(异或),得到第一个明文块。

然后，CBC将加密算法的逆运算应用于第二个密文块，并将该块与第一密文块进行XOR，得到第二个明文块。这个过程将一直持续到消息被解密。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

因为每个输入块(除了第一个)都依赖于前一个块被加密，CBC不能并行地进行加密。然而，由于解密需要(立即可用)密文块进行XOR，所以它可以并行进行。CBC是最常用的模式之一。

于ECB相似，要使用这种模式正常工作，消息的长度需要是块大小的两倍，不足要进行填充来满足长度。

Cipher Feedback Mode (CFB 加密反馈模式)

CFB与CBC相似，但CFB不是使用整个前一个密文块计算下一个块，而是前一个块的一部分。

1 CFB从一个与加密块预期大小相同的IV开始，使用加密算法对其进行加密。

2 CFB保留s(重要)字节，并将其与要传输的明文s字节进行XOR(异或)。

3 然后，CFB将IV的s字节向左移动，将步骤2 产生的密文字节插入右边的字节中(IV保持相同的长度)。

4 然后重复这些步骤。

为了解密消息，CFB使用IV作为第一个块，并通过执行上述步骤3和应用加密算法形成块形成每个后续块。然后，CFB与 s字节相应的密文进行XOR(异或)，以显示明文。

在CFB内部，加密系统一次处理 s < b明文位，即使算法本身进行 b-bits到 b-bits的转换。这意味着s 可以是任何数字，包含一个1个字节，CFP可以在流加密中作为一个功能运行。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

不幸的是，这意味着CFB可以向下游传播错误。如果收到一个错误的字节，当CFB用它来解密第一个字节时，它将产生一个错误的解密，导致后面的解密错误。

像CBC一样，当CFB加密时，每轮的输入都依赖于前一轮的结果，这意味着加密不能并行进行，尽管如果输入块首先由IV和密文创建，则可以并行进行解密。

Output Feedback (OFB 输出反馈)

OFB与CFB类似，但它不是将 s<b 位处理转换成 b-bits to b-bits，而是直接s位处理。与CFB类似，OFB可以在流加密中使用。

OFB要求IV是唯一的nonce(一次性使用)，用于给定的密钥每次执行。

首先，OFB加密算法对IV进行加密，产生一个块。然后，OFB将此块与一个明文块进行XOR,产生第一密文块。

OFB用加密算法对第一个输出块进行加密，输出第二个输出块。然后，它将此块与第二个明文块进行XOR(异或)，产生第二个密文块。OFB在信息的长度上重复这一过程。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

解密时，OFB用加密算法对IV进行加密，产生一个输出块。然后OFB将此块与第一个密文块进行XOR(异或),恢复第一个明文块。

OFB用加密算法对第一个输出块进行加密，产生第二个输出块。然后OFB将其与第二个密文块进行XOR，恢复第二个明文块。OFB为信息的长度重复这一过程。

由于用于解密的输出块是本地生成的，OFB比CFB更能抵抗传输错误。

Counter (CTR 计算器)

CTR将加密算法应用于一组独特的输入块（计数器），以产生输出，这些输出与明文进行XOR(异或)以产生密码文本。

CTR用加密算法对第一个计数器进行加密，然后将产生的输出与第一个明文块进行XOR，产生第一个密文块。CTR对每个区块重复这一过程（有一个新的计数器--计数器在使用单一密钥加密的所有信息中必须是唯一的）。

如果最终的块是一个s字节的部分块(输出块的最重要的位)，s被用于XOR，而输出块的b-s字节被丢弃。

https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

解密也遵循同样的模式。CTR用加密算法对计数器进行加密，然后将输出与相应的密文块进行XOR，产生明文块。

如果最终的块是一个s字节的部分块(那么输出块的最重要的比特)。s，被用于XOR，而输出块的b-s字节被丢弃。

CTR已被证明至少与其他四种模式一样安全，同时还能够并行执行（包括加密和解密），这意味着它非常快。

如果可以确定每个区块的计数器区块，并且可以在收到明文或密文之前对计数器进行加密（如果内存不受限制），那么每个区块都可以独立恢复。

更多请阅读: NIST Recommendation for Block Cipher Modes of Operation

攻击者如何试图破解加密?

攻击者使用的技术有很多，但根据实施攻击所需的信息，它们大致可分为以下几类。

这并不是一个详尽的清单（还有其他攻击，如侧信道攻击），但许多最常见的攻击都属于这些类别之一。

已知密文攻击

攻击者拥有一些密码文本，但不知道用什么明文来生成这个密码文本。攻击者不能选择他们所拥有的密码文本，他们也不能获得/产生更多的密码文本。

这是最容易尝试的攻击类型，因为窃听加密对话是最容易的（因为假定进行对话的人使用强大的加密技术，并不担心窃听者）。但这是最难成功的，只要发送信息的人使用适当的强加密。

例如: David 发现一个加密信息 (密文) 在死角，但不知道这条消息是什么意思。

已知明文攻击

攻击者拥有一些他们没有选择的明文和密文对（所以攻击者没有选择被加密的信息，但能够成功窃取明文信息和其相关的密文）。攻击者不能获得/产生更多的相关信息。

例如，大卫发现了一个敌方间谍的藏身之处，并在间谍发送加密信息时打断了他。这个间谍傻乎乎地逃走了，留下了明文信息和其相关的密码文本的记录。

选定明文攻击

攻击者可以选择任何明文并获得密文(但他们不能看到密钥本身)。

这进一步细分为批量选择的明文（攻击者可以提交一组明文并收到密文，但不能再次这样做）和调整选择的明文（攻击者可以提交明文，并根据以前的密码文本提交额外的明文，获得新的密文）。

例如：民族国家A正在窃听另一个民族国家B的加密通信，并且知道A和B所有的加密都使用同一个密钥。A和B向另一个民族国家C发送了一份敏感的外交通讯，知道它将通过加密通道传输，从而给他们提供了一个选定的明文--密文对。

选定密文攻击

这与上一种攻击相反，攻击者可以选择任何密码文本并获得明文作为回报（但他们不能看到密钥本身）。

_比如说：David 知道敌方间谍明天要发送一份加密信息，所以他用自己选择的密文替换原密文，然后监视收件人，听他们读出信息的明文。 _

资料来源/更深入阅读:

• NIST Recommendations for Block Cipher Modes of Operation
• Diffusion and Confusion
• Confusion and Diffusion
• Kerckhoffs's Principle
• Padding Mechanisms
• Foundations of Computer Science: Stream and Block Encryption

原文：Cipher Definition – What is a Block Cipher and How Does it Work to Protect Your Data，作者：Megan Kaczanowski

什么是模糊测试？

模糊测试 是一种自动测试软件的方式。模糊器（fuzzer） 会向程序输入一系列的无效或随机的数据。这个测试尝试去造成程序崩溃、错误和内存泄漏等异常。

一般来说，模糊测试 在一些接受用户输入的程序中工作的最好，比如那些要求用户输入姓名和年龄的网站。

我们可以输入各种字符串来尝试引发程序问题，比如：“Powerلُلُصّبُلُلصّبُررً ॣ ॣh ॣ ॣ冗”（过去这个字符串会导致 iOS 系统崩溃）、“Ṯ̤͍̥͇͈h̲́e͏͓̼̗̙̼̣͔ ͇̜̱̠͓͍ͅN͕͠e̗̱z̘̝̜̺͙p̤̺̹͍̯͚e̠̻̠͜r̨̤͍̺̖͔̖̖d̠̟̭̬̝͟i̦͖̩͓͔̤a̠̗̬͉̙n͚͜ ̻̞̰͚ͅh̵͉i̳̞v̢͇ḙ͎͟-҉̭̩̼͔m̤̭̫i͕͇̝̦n̗͙ḍ̟ ̯̲͕͞ǫ̟̯̰̲͙̻̝f ̪̰̰̗̖̭̘͘c̦͍̲̞͍̩̙ḥ͚a̮͎̟̙͜ơ̩̹͎s̤.̝̝ ҉Z̡̖̜͖̰̣͉̜a͖̰͙̬͡l̲̫̳͍̩g̡̟̼̱͚̞̬ͅo̗͜.̟”、“😍” 或 “undefined”。

模糊测试 背后的思想是尝试找出代码的边界情况。用它来确保所有的数据输入、解析、存储和数据访问不会引发程序错误。

它也是一种相当完整的测试，因为你可以测试在网站中存储数据（如零宽空格，即 Unicode 中的 U+200B）的完整流程，来检测程序问题。

有些人会尝试在输入框中注入代码（这是 模糊测试 的一部分，称为 代码注入），比如将 <script>alert(123)</script> 作为姓名输入。

恶意的黑客不希望你测试非标准的输入，这样你的程序就可能留有破坏性的漏洞——他们可以利用它来窃取数据或者让你的应用或服务器一直崩溃。

可以查看一下这个名为“顽皮字符串大清单”的 Github 仓库，其中列出了很可能引发程序问题的字符串。

可以查看其中的 .json 和 .txt 文件来了解哪些字符串在过去曾经引发过问题，还可以通过查看评论来理解为什么它们会引发问题。

例如，有些字符串是上下颠倒的（“upside-down”——“uʍop-ǝpᴉsdn”），可以在这里试试。有些字符串可能被标记为亵渎或不当言论，但事实上并无恶意（这被称为 Scunthorpe 问题）。有些字符串被配置不当的 XML 解析器解析之后甚至会暴露系统文件。

谁在使用模糊测试？

我之前已经有提到过，模糊测试 作为 软件测试 的一部分来检测程序错误。不过它在网络安全和黑客攻击中也有应用。

在网络安全应用中，黑客寻求越过 安全边界(trust boundary)。安全边界 是计算机系统中把数据从一个区域（受信任的源）传递到另一个区域的地方。（注：维基百科中信任边界的定义。）

想象一下前端界面接受用户姓名作为输入数据，确认有效后传入后端，这里的信任边界就是从前端到后端传递数据的路径中假想的那条线。

如果后端只是信任数据而不去验证它的话（因为前端已经验证过了），可能会引发问题。只要黑客能够通过前端检查，他们就会被当成 受信任 的输入，就可以尝试插入恶意字符串作为输入数据传入后端。

这里，模糊测试 可以帮助抽查以确保你的代码正确地捕获和处理了这些问题。

假如有人要模糊 Google Chrome，一种可能的方式是在调试工具中运行浏览器，从而追踪 Chrome 执行的命令、分析其内存管理。

之后黑客会让监控中的 Chrome 指向他们的服务器，黑客服务器会创建数百万个网页让 Chrome 加载，所有页面中的 JS、CSS 和 HTML 都略有不同，尝试使得监控中的 Chrome 崩溃。

黑客会持续运行这些自动测试长达数月，收集大量的 Chrome 日志（如崩溃、内存溢出等），尝试找出导致崩溃的原因。

仅仅导致崩溃不是最终目标，一旦这些黑客知道了何种输入会导致崩溃，他们可以研究这些东西是如何导致崩溃的，并利用这些漏洞来干一些邪恶的事或者访问一些原本无权访问的数据。可以在这里阅读关于以上示例的更多信息。

Google 目前在 30,000 个虚拟机中 模糊（fuzz） 他们自己的应用！因为他们的测试已经覆盖得相当广泛，所以黑客不太可能取得任何进展。

Google 的 OSS-Fuzz 已经在 Chrome 代码中找到 25,000+ 个 bug，在其他开源代码库中找出了大约 22,500 个 bug。

回到主题，谁在使用 模糊测试？我敢打赌，几乎所有要保护电子资产或信息的公司都会请测试人员对其产品做 模糊测试 或者是自己做测试。

总结

希望本文阐明了什么是 模糊测试 以及它的用途。

如果你想要更深入地研究这个主题，可以在这里找到大量相关资源，包括教程、视频和工具等，可以帮助你学习 模糊测试。

如果你喜欢本文，可以阅读我在 Twitter 上分享的更多文章。

原文：What is Fuzzing? Fuzz Testing Explained with Examples，作者：Kealan Parr