跨站点脚本(XSS)和跨站点请求伪造(CSRF).docVIP

在本文中，我将深入探讨以下两种更常见的攻击，以帮助完善我们的应用程序保护体系：跨站点脚本 (XSS) 和跨站点请求伪造 (CSRF)。 您可能很想知道： 只使用生产安全扫描程序不就行了吗？扫描程序是查找容易实现的目标的绝佳工具，它们尤其适合查找应用程序和系统配置问题，但它们无法像您一样了解您的应用程序。因此，您必须熟悉潜在的安全问题，花点时间检查应用程序并为您的软件开发生命周期构建安全性。 跨站点脚本 简介 XSS 攻击是指将脚本恶意注入用户的浏览会话，这通常在用户不知情的情况下发生。因为一些事故的发生，许多人已经非常熟悉这些类型的攻击，在这些事故中，某大型社交网站受到攻击，其用户发布了他们未授权的消息。如果攻击者发布恶意脚本并且他可以让浏览器执行该脚本，则该脚本将在受害者会话的上下文中执行，这基本上使攻击者能够对 DOM 执行其所需的任何操作，包括显示伪造的登录对话框或盗取 Cookie。此类攻击甚至可以在当前页面上安装 HTML 键记录器，以便持续将来自该窗口的输入内容发送到远程站点。 参数篡改的使用方式 攻击者通过多种方法利用 XSS，所有这些方法都需要有未封装或封装不当的输出。下面我们以需要向最终用户显示简单的状态消息的应用程序为例。通常，该消息通过查询字符串传递，如图 1 所示。 图 1 查询字符串消息 该方法通常在重定向之后使用以便向用户显示某种状态，例如图 1 中的“Profile Saved”（配置文件已保存）消息。该消息从查询字符串读取并输出到页面中。如果输出内容未经过 HTML 编码，任何人都可以轻松地注入 JavaScript 来代替状态消息。此类攻击被视为反射 XSS 攻击，因为无论查询字符串中有什么内容，它都会呈现在页面中。在持续性攻击中，恶意脚本通常存储在数据库或 Cookie 中。 在图 1 中，您可以看到此 URI 使用了一个 msg 参数。此 URI 的网页将包含如下代码以便将变量写入页面而不进行编码： div class=messages %=Request.QueryString[msg]%/div 如果将“Profile Saved”替换为图 2 中显示的脚本，浏览器中将会弹出查询字符串中包含的脚本的警报功能。此处的漏洞利用的关键在于结果没有经过 HTML 编码，因此浏览器实际上将 script 标记解析为有效 JavaScript 并执行。这显然不是开发人员的初衷。 图 2 将脚本注入 URI 中 那就弹出警报吧—有什么大不了的？下面我们进一步看看该示例，如图 3 所示。请注意，为了便于说明，我已经缩短了此处的攻击；此语法并不完全正确，但些许的修改会使其成为真正的攻击。 图 3 创建恶意攻击 类似这样的攻击可能导致向用户显示伪造的登录对话框，用户会轻易地在其中输入他们的凭据。在本例中，将会下载一个远程脚本，默认浏览器安全设置通常允许这种行为。理论上，只要可以将尚未编码或净化的字符串回显给用户，就可能会发生此类攻击。 图 4 显示了在开发站点上使用类似脚本的攻击，该站点允许用户留下有关其产品的意见。不过，有些人不是留下真正的产品评论，而是输入了恶意 JavaScript 作为意见。该脚本现在将向访问该网页的每个用户显示一个登录对话框，收集凭据然后将凭据发送至远程站点。这是一种持续性 XSS 攻击；脚本存储在数据库中，并对每个访问该页面的人重复执行。 图 4 显示伪造对话框的持续性 XSS 攻击 攻击者利用 XSS 的另一方法是通过使用 HTML 元素，例如 HTML 标记中允许使用动态文本时，如下所示： img onmouseover=alert([user supplied text]) 如果攻击者注入“onmouseout=alert(document.cookie)”之类的文本，这将在访问 Cookie 的浏览器中创建以下标记： img onmouseover=alert(1) onmouseout=alert(document.cookie) 没有用于潜在地筛选输入内容的“script”标记，也没有需要封装的内容，但这是可以读取 Cookie（可能是一个身份验证 Cookie）的完全有效的 JavaScript。可根据具体情况采取具体措施提高安全性，但由于存在风险，最好禁止任何用户输入访问此处的这些内嵌代码。 防范 XSS 的方法 严格遵守以下规则将有助于防范应用程序中的大多数（即使不是全部）XSS 攻击： 确保所有输出内容都经过 HTML 编码。 禁止用户提供的文本进入任何 HTML 元素属性字符串。 根据 /library/3yekbd5b 中的概述，检