Web应用程序中的常见安全漏洞( 二 ) _安全漏洞

让我们举个例子。用户在web应用程序中发布消息或评论。发布消息后，该站点将显示它，以便访问该页面的每个人都可以看到它。每天可能有数百人访问这个页面，这取决于该网站的受欢迎程度。对于我们的示例，我们将认为它是一个已知的站点，并且有大量的个人访问它的页面。如果该用户发布了一个脚本，当在web页面上找到该脚本时，浏览器会执行该脚本(图1.6和1.7)，该怎么办?

文章插图
图 1.6
一个用户在网络论坛上发布了一个包含脚本的评论。用户定义脚本，以便发出请求，试图发布或从另一个应用程序(App X)获取大量数据，该应用程序代表攻击的受害者。如果web论坛应用程序允许跨站脚本(XSS)，那么显示带有恶意评论的页面的所有用户都会收到它。

文章插图
图 1.7

用户访问显示恶意脚本的页面。他们的浏览器执行脚本，然后尝试发布或从App X获取大量数据。
什么是跨站请求伪造(CSRF)?跨站请求伪造 (CSRF) 漏洞在web应用程序中也很常见。CSRF 攻击假设可以从应用程序外部提取并重用调用特定服务器上的操作的 URL (图1.8) 。如果服务器信任执行而不检查请求的来源，则可以从任何其他地方执行。通过 CSRF，攻击者可以通过隐藏操作，让用户在服务器上执行不需要的操作。通常，通过此漏洞，攻击者的目标是更改系统中的数据的操作。

文章插图
图 1.8
跨站点请求伪造（CSRF）的步骤。登录他们的帐户后，用户访问包含伪造代码的页面。然后，恶意代码代表毫无戒心的用户执行操作。
缓解此漏洞的方法之一是使用令牌来标识请求或使用跨域资源共享（CORS）限制。换句话说，请验证请求的来源。在后面章节中，我们将详细介绍 Spring Security 如何处理 CSRF 和CORS 漏洞。
了解web应用程序中的注入漏洞对系统的注入攻击非常普遍。在注入攻击中，利用漏洞的攻击者会将特定数据引入系统。目的是损害系统，以不必要的方式更改数据或检索攻击者不希望访问的数据。
注入攻击有很多类型。甚至我们在前面章节中提到的 XSS 都可以视为注入漏洞。最后，注入攻击会注入客户端脚本，从而以某种方式损害系统。其他示例可能是 SQL 注入，XPath 注入，OS 命令注入，LDAP 注入等等。
漏洞的注入类型很重要，利用这些漏洞的结果可能是更改、删除或访问系统中的数据遭到破坏。例如，如果您的应用程序在某种程度上容易受到 LDAP 注入的攻击，那么攻击者可以通过绕过身份验证，从而控制系统的基本部分而获益。XPath 或 OS 命令注入也会发生同样的情况。
SQL 注入是最古老的、可能也是众所周知的一种注入漏洞。如果您的应用程序有 SQL 注入漏洞，攻击者可以尝试更改或运行不同的 SQL 查询，以更改、删除或从您的系统中提取数据。在最高级的 SQL 注入攻击中，个人可以在系统上运行 OS 命令，从而导致整个系统的危害。
处理敏感数据的泄露即使就复杂性而言，机密数据的披露似乎是最容易理解、最不复杂的漏洞，但它仍然是最常见的错误之一。之所以会出现这种情况，可能是因为在网上找到的大多数教程和示例，以及说明不同概念的书籍，为了简单起见，都直接在配置文件中定义了凭据。如果一个假设的例子最终集中在其他事情上，这就说得通了。

注意:
大多数时候，开发人员会不断地从理论例子中学习。一般来说，为了让读者专注于一个特定的主题，例子会被简化。但是这种简化的缺点是开发人员习惯了错误的方法。开发人员可能会错误地认为他们读到的所有东西都是好的实践。

这个方面与 Spring Secyrity 有什么关系?我们将在本书的示例中处理凭证和私钥。我们可能会在配置文件中使用 secrets，但是我们会为这些情况做一个说明，以提醒您应该将敏感数据存储在金库中。当然，对于一个已开发的系统，开发人员不允许在所有环境中看到这些敏感键的值。通常，至少在生产中，只有一小部分人应该被允许访问私人数据。
通过在配置文件中设置此类值，例如 Spring Boot 项目中的 application.properties 或 application.yml 文件，您可以使那些可以看到源代码的人访问这些私有值。此外，您可能还会发现自己将这些值更改的所有历史记录存储在源代码的版本管理系统中。