Web安全导论概要.ppt
文本预览下载声明
A8-跨站请求伪造（CSRF） 威胁代理 攻击向量 安全漏洞 技术影响 业务影响 应用描述 可利用性 平均 普遍性 常见 可检测性 易 影响 中等 应用/业务描述 考虑可能将内容载 入你用户的浏览器 并迫使他们向你的 网站?交请求的任 何人。你的用户所 访问的任何网站或 者HTML源（feed） 都可以这样做。 攻击者创建伪造 HTTP请求并通过图 片标签、跨站脚本 或许多其他技术诱 使受害用户?交这 些请求。如果该受 害用户已经经过身 份认证，那么攻击 就能成功。 CSRF是利用某些web应用程序允许攻击 者预测一个特定操作的所有细节这一特 点。 由于浏览器自动发送会话cookie等认证 凭证，攻击者能创建恶意web页面产生 伪造请求。这些伪造请求很难与合法请 求区分开。 跨站请求伪造漏洞可以很容易通过渗透 测试或代码分析检测到。 攻击者能欺骗受害 用户完成该受害者 所允许的任意状态 改变的操作，比如： 更新帐号细节，完 成购物，注销甚至 登录等操作 。 考虑受影响的数据 和应用功能的商业 价值。 试想如果 并不知道这些操作 是否是用户的真正 意愿会产生什么后 果。 同时考虑带来的声 誉影响。 一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的HTTP请求，包括该用户的会话cookie和其他认证信息，发送到一个存在漏洞的web应用程序。这就允许了攻击者迫使用户浏览器向存在漏洞的应用程序发送请求，而这些请求会被应用程序认为是用户的合法请求。 检测应用程序是否存在该漏洞的方法是查看是否每个链接表单都提供了不可预测的CSRF令牌。没有这样的令牌，攻击者就能够伪造恶意请求。另一种防御的方法是要求用户证明他们要提交请求，可以通过重新认证的方式或者其他能够证明他们是真实用户的方法（比如：CAPTCHA）。重点关注那些调用能够改变状态功能的链接和表格，因为他们是跨站请求伪造攻击的最重要的目标。由于多步交易并不具备内在的防攻击能力，因此我们需要检测这些交易。攻击者能轻易使用多个标签或JavaScript伪造一系列请求。 请注意：会话cookie、源IP地址和其他浏览器自动发送的信息不能作为防攻击令牌，因为这些信息已经包含在伪造的请求中。 攻击案例 应用程序允许用户提交不包含任何保密字段的状态改变请求，如： /app/transferFunds?amount=1500desknakonAccount=4673243243，因此，攻击者构建一个请求，用于将受害用户账户中的现金转移到自己账户。然后攻击者在其控制的多个网站的图片请求或iframe中嵌入这种攻击。 imgsrc=/app/transferFunds?amount=1500desknakonAccount=a\ackersAcct#width=0height=0/ 如果受害用户通过认证后访问任何一个攻击者的网站，伪造的请求将自动包含用户的会话信息，授权执行攻击者的请求。 如何防止？ 防止跨站请求伪造，通常需要在每个HTTP请求中添加一个不可预测的令牌。这种令牌至少应该对每一个用户会话来说是唯一的。 最好的方法是将独有的令牌包含在一个隐藏字段中。这将使得该令牌通过HTTP请求体发送，避免其包含在URL中从而被暴露出来。 该独有令牌同样可以包含在URL中或作为一个URL参数。但是这种方法的巨大风险在于：URL会暴露给攻击者，这样秘密令牌也会被泄漏。 A9-使用含有已知漏洞的组件 威胁代理 攻击向量 安全漏洞 技术影响 业务影响 应用描述 可利用性 平均 普遍性 广泛 可检测性 难 影响 中等 应用/业务描述 一些含有漏洞的组 件（如：框架库） 可以被自动化工具 发现和利用。这使 得威胁代理部分引 入了“混乱”的角 色，而不仅仅是攻 击者了。 攻击者通过扫?或 手动分析识别问题 组件，然后根据需 要定制攻击代码并 实施攻击。在应用 中使用组件越深入， 实施攻击的难度越 大。 事实上，大多数的应用都存在这些问题。 因为大多数的开发团队并不会把及时更 新组件/库作为他们的工作重心。在很 多情况下，开发者都不了解他们所使用 的全部组件，更不用说组件的版本了。 组件的依赖性使情况更加糟糕。 可能是由低到高全 系列的漏洞，包括 注入，破损的访问 控制，XSS等。受 影响范围也从最低 的受损到主机被完 全接管和数据的泄 漏。 考虑一下受影响的 应用中，每个脆弱 点对业务控制来说 意味着什么。可能 是非常细微的影响， 也有可能意味着被 完全攻破。 组件，比如：库文件、框架和其它软件模块，几乎总是以全部的权限运行。如果一个带有漏洞的组件被利用，这种攻击可以造成更为严重的数据丢失或服务器接管。应用程序使用带有已知漏洞的组件会破坏应用程序防御系统，并使一系列可能的攻击和影响成为可能。 理论上，应该是很容易确定您
显示全部