网络安全 Web 应用程序攻击
如今，Web 应用程序无处不在，它们被用来控制几乎所有你能想象到的东西。在本节中，我们将探讨 Web 应用程序的攻击和安全。
IDOR（“不安全的直接对象引用”）
当开发人员未实现访问资源的授权要求时，就会出现 IDOR 漏洞。
Eve，只需更改一个标识符，例如文档 Rest 参数，她就可以访问 Alice 的文档。
当 Web 应用程序未能强制执行对象之间的授权时，就会发生这种情况，允许攻击者枚举值并测试对其他数据点的访问。
例如，我们可能有以下伪代码，其中没有显示任何授权迹象
$id = getInputFromUser();
$doc = getDocument($id);
return $doc;上面的代码要求用户输入，不进行任何验证或清理，然后直接使用 getDocument 函数进行查找并返回所请求的文档。
更好的实现是检查权限
$id = getInputFromUser();
$user = findUsername();
$doc = "";
if (hasAccessToDocument($user, $id)) {
$doc = getDocument($id);
} else {
$doc = "Not authorized for this document";
}
return $doc;
像这样的漏洞很容易找到，因为您只需更改一个简单的数字，然后查看是否可以访问他人的数据。首先检查用户是否已授权可以防止此漏洞。
避免“魔术数字”
应用程序想要避免在引用数据时使用数字序列。在 IDOR 示例中，文档的标识符是 1000 到 1002。有时这些数字被称为“魔术数字”，因为它们直接指向服务器上的资源（例如，通过数据库），并且所有值都可以轻松枚举。例如，攻击者可以检查从 0 到 10000 的所有文档标识符，并记录任何提供数据访问的结果。
虽然应该正确实现授权，但使用 GUID（“全局唯一标识符”）或 UUID（“通用唯一标识符”）引用数据也很有帮助。这些标识符被设计为全局唯一且由于生成数字的内置熵而无法枚举。
GUID 可能看起来像这样
- 3377d5a6-236e-4d68-be9c-e91b22afd216
SQL 注入
许多 Web 应用程序都连接到数据库。数据库存储了 Web 应用程序希望存储和使用的所有信息。
SQL 注入是一种允许攻击者操纵 Web 应用程序开发人员使用的 SQL（“结构化查询语言”）的技术。这通常是由于缺乏数据清理而发生的。SQL 被开发人员经常用于访问数据库资源。
在上面图形中 Eve 发出的请求中，我们看到她输入的值是：1000' OR '1'='1
这会导致结果 SQL 查询返回表中的所有行，因为数据库将该语句评估为始终为真。 想一想：数据库收到一个请求，其中值可以是 1000 或 1 等于 1；它每次都会返回一个值！我们可以使用许多不同的 SQL 函数和操作来操纵语法，这个例子只是众多例子中的一个。
下面是一个包含 SQL 注入漏洞的伪代码示例。
$username = getUserName();
$pw = getPassword();
$user = mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}
为了让攻击者利用这一点，他们可以简单地针对目标域构建一个包含攻击的 URL，如下所示
/login?username=admin&password=password' OR '1'='1密码变量设置为包含 SQL 字符，导致生成的 SQL 字符串返回一行，即使我们不知道密码。生成的 SQL 查询将是
SELECT * FROM userTable WHERE username = 'admin' AND password = 'password' OR '1'='1'参数化查询是击败 SQL 注入的推荐解决方案。在参数化查询中，开发人员会仔细确保查询的每个输入都被定义为特定的值和类型。下面是一个来自上述代码的示例，该示例被认为是一个安全的实现：
$username = getUserName();
$pw = getPassword();
$parameterizedQuery = prepare_query("SELECT * FROM userTable where username = ? and password = ?");
$parameterizedQuery.setString(1, $username)
$parameterizedQuery.setString(2, $password)
$user = parameterizedQuery.execute();
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}在上面的示例中，开发人员已仔细说明参数 1 应为字符串并包含用户名，第二个参数包含密码。
XSS（“跨站脚本”）
XSS 使用服务器来攻击服务器的访问者。该攻击不针对服务器本身，而是针对用户。
服务器仅用于将攻击者的值（通常是 JavaScript）反射给访问者，然后访问者在自己的浏览器中运行攻击者的数据。攻击者必须构造一个服务器不清理和过滤的输入，这样，当访问者单击包含攻击者值的链接，或访问攻击者在其攻击中使用的网页上的资源时，用户就会运行攻击者提供的代码。
下面是 Eve 向 Alice 发送包含 XSS 攻击的链接的图形示例
这种攻击称为反射型 XSS，涉及 Eve 找到漏洞，然后向毫无戒心的用户发送包含攻击的链接，并让他们单击该链接。该链接包含攻击，并使 Web 服务器将攻击返回给点击该链接的受害者。
背后的代码可能是这样的伪代码示例
$nickname = etNickName();
echo "Greeting $nickname, nice to meet you!";另一种 XSS 称为存储型 XSS 攻击。在存储型 XSS 攻击中，攻击者能够将内容保存在网页上，而这些内容在每次有人访问该网站时都会被反射。它不一定需要有人点击链接。
此图形描述了 Eve 如何能够存储恶意 JavaScript，以便在任何人访问该资源时在其浏览器中执行
XSS 攻击可以完成许多事情，例如
- 窃取可用于身份验证的 cookie
- 篡改网站，呈现 Web 服务器未打算使用的内容
- 通过网络钓鱼让用户在假登录表单中留下凭据
为了防御 XSS，有几项最佳实践需要遵循
- 让 Web 服务器返回 CSP（“内容安全策略”）标头，该标头严格决定 JavaScript 的来源和执行方式
- 安全地编码 Web 服务器返回给用户的输出，有效地将 HTML 字符转换为编码的安全字符
HTML 编码
HTML 编码允许 Web 应用程序以安全的方式返回通常不安全的字符。例如，以下特殊字符可以编码为其对应的字符
| 特殊字符 | HTML 实体 |
|---|---|
| < | < |
| > | > |
| " | " |
| & | & |
| ' | ' |
这会生成可以安全显示的输出。然后，我们可以使用客户端的 JavaScript 将 HTML 实体安全地转换为值。
CSP（“内容安全策略”）
Web 服务器可以控制允许在网站上运行哪些类型的 JavaScript。这并不能消除漏洞，但当存在未知漏洞时，它会增加纵深防御。
一种常见且严格的 CSP 是为 Web 应用程序用户提供所有接受的 JavaScript 源文件的列表。
此外，CSP 通常会阻止执行内联 JavaScript。
为了更轻松地实现和检测正在进行的攻击，CSP 允许客户端将 CSP 违规报告给服务器提供的 URL。
Web 应用程序扫描
市面上有许多 Web 应用程序扫描器。它们允许扫描应用程序是否存在 SQL 注入和 XSS 等漏洞。与网络漏洞扫描器相反，Web 应用程序扫描器通常基于启发式方法而不是签名和已知漏洞列表。
Web 应用程序扫描器非常有用，特别是当它们集成到 CI（“持续集成”）和 CD（“持续交付”）等开发流程中时。
