您的位置:首页 > 移动开发

AppScan 测出 跨站点请求伪造 漏洞

2016-12-15 13:30 260 查看
安全风险:可能会窃取或操纵客户会话和 cookie,它们可能用于模仿合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务
可能原因

应用程序使用的认证方法不充分

技术描述

“跨站点伪造请求 (CSRF)”攻击可让黑客以受害者的名义在易受攻击的站点上运行操作。当易受攻击的站点未适当验证请求来源时,便可能出现这个攻击。

这个漏洞的严重性取决于受影响的应用程序的功能,例如,对搜索页面的 CSRF 攻击,严重性低于对转帐页面或概要更新页面的 CSRF 攻击。
这项攻击的执行方式,是强迫受害者的浏览器向易受攻击的站点发出 HTTP 请求。如果用户目前已登录受害者站点,请求会自动使用用户的凭证(如会话 Cookie、用户的 IP 地址,以及其他浏览器认证方法)。攻击者利用这个方法来伪造受害者的身份,再代替他来提交操作。换句话来说,易受攻击的站点未采取适当措施来验证用户实际是否想执行特定操作。
强迫受害者发送非预期的请求,方法有许多种:
- 通过电子邮件向受害者发送易受攻击应用程序的恶意链接。
- 在黑客的 Web 页面上,放置一个易受攻击的站点的热链接(如图像或帧)。
- 在公共论坛中,张贴易受攻击站点的链接。
- 利用站点(或另一个站点)的“跨站点脚本编制”或“链接注入”漏洞,将浏览器自动重定向到易受攻击的站点。
如果攻击者利用易受攻击的站点本身的“链接注入”漏洞,可以增加用户通过站点认证的可能性,进而增加攻击成功的可能性。
例如,攻击者可以利用上述任何选项来诱惑受害者查看含有下列条目的页面:
<img src="http://bank/transfer?destination=John&money=1000" style='visibility:hidden'>

这会使受害者的浏览器自动请求 URL 及浏览器的当前凭证。

如果这个银行业站点易受到 CSRF 攻击,它会根据应用程序逻辑,从受害者的帐户中,将 1000 美元转账到 John 的银行帐户。

“跨站点伪造请求”攻击也称为 CSRF(发音为 C-Serf)、XSRF、“跨站点伪造引用”、“单键攻击”以及“会话骑乘”。
您可以利用下列方式来验证您的应用程序是否易受到 CSRF 攻击:
[1] 检查易受攻击的链接/请求是否未包括攻击者难以猜中的参数
[2] 检查易受攻击的链接/请求是否会执行只应自愿执行的操作
含有用户在不知不觉中提交的请求所能直接访问的敏感操作的应用程序,被视为很容易遭受 CSRF 攻击。CSRF 也可能出现在登录页面和注销页面上。由于攻击者可以伪造来自受害者的连续注销请求,因此 CSRF 可能导致服务拒绝。在登录页面上,CSRF 可以允许攻击者使用包含攻击者用户名和密码的伪造请求来将客户机登录到攻击者的账户中。登录 CSRF 攻击会带有严重的后果,这取决于其他站点行为。例如,如果站点保留了用户操作的历史记录(例如搜索历史记录),那么攻击者将能够在易受攻击的站点上查看受害者之前执行的操作。

修订建议
一般

如果要避免 CSRF 攻击,每个请求都应该包含唯一标识,它是攻击者所无法猜测的参数。 建议的选项之一是添加取自会话 cookie 的会话标识,使它成为一个参数。服务器必须检查这个参数是否符合会话 cookie,若不符合,便废弃请求。 攻击者无法猜测这个参数的原因是应用于 cookie 的“同源策略”,因此,攻击者无法伪造一个虚假的请求,让服务器误以为真。 攻击者难以猜测且无法访问的任何秘密(也就是无法从其他域访问),都可用来替换会话标识。 这可以防止攻击者设计看似有效的请求。


解决方案

建议用户每次登录时需使用新的会话标识。应用程序实现上就是在登录模块,添加以下代码,即用户登录后,重新生成会话。

HttpSession session = request.getSession(false);
if(session!=null){//让cookie过期
session.invalidate();
Cookie cookie = request.getCookies()[0];//获取cookie
cookie.setMaxAge(0);//让cookie过期
}
request.getSession(true);//生成新会话经过测试,这段代码只在weblogic和tomcat下才有效,在公司中间件webspeed及jboss6.0下问题都依然存在,但从扫描的结果信息分析看,漏洞已经解决,分析判断应该只是session处理机制不同,AppScan工具仍认为存在漏洞风险。在与电信沟通中我们存在一个经验教训大家一定要吸取,不能过渡迷信流行的自动化测试工具,尤其是对于Appscan这种判断防御行为的复杂软件,仅靠有限的规则设置就当做是web安全的唯一标准这显然不太合理,这种情况一定要与测试方沟通解释。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: