10大最重要的Web安全风险之五：A5-伪造跨站请求

时间 2019-11-11

标签最重要 web 安全风险之五 a5 伪造请求栏目 HTML 繁體版

原文原文链接

10大最重要的Web安全风险之五：A5-伪造跨站请求（CSRF） php

OWASP TOP10

A1-注入 html

A2-跨站脚本（XSS） java

A3-错误的认证和会话管理 web

A4-不正确的直接对象引用 api

A5-伪造跨站请求（CSRF） -- Cross-Site Request Forgery 跨域

A7-限制远程访问失败浏览器

A8-未验证的重定向和传递安全

A9-不安全的加密存储服务器

A10-不足的传输层保护 cookie

A5-伪造跨站请求（CSRF）

一个跨站请求伪造攻击会强制一个已登陆的受害者的浏览器向服务器（有缺陷站点）发送一个伪造的HTTP请求，这个请求会包括受害者的session cookie以及其余自动产生的认证信息，这会使得服务器（有缺陷站点）认为收到的受害者请求是合法请求。

伪造跨站请求问题概述

伪造跨站请求问题的几个特色

攻击者：任何可能诱骗用户向系统提交请求的人。合法用户访问的任何站点或HTML页面均可能有此行为。

漏洞利用手段：利用难度通常。攻击者建立一个伪造的HTTP请求而且诱骗受害者经过图片标记（image tags）、XSS或者其余技术提交这些请求。若是受害者自己已经在系统中登陆（已认证），则攻击成功。。

保护和检测机制：经过入侵检测或者代码分析能够较为容易的发现CSRF漏洞。

影响： 危害中等。存在这种缺陷的状况下，攻击者能够改变受害者有权限改变的任何数据或调用受害者有权限使用的任何功能。

典型的伪造跨站请求问题

若是一个Web应用容许用户提交一个未包含任何秘密（不可预测内容）的状态变动（本例中是转帐）请求，如：

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

当攻击者构造一个请求，将受害者的账号中的金钱进行转帐，并将这个请求包含在一个其余站点的图片请求或iframe请求中，以下：

.<imgsrc="http://example.com/app/transferFunds?amount=1500&destinationAccount=attackersAcct#“width="0" height="0" />

若是受害者已经登陆转帐系统，而且访问了这个包含了恶意请求的连接，则这个伪造请求会包含受害者的session会话信息及其余认证信息。

系统中是否存在伪造跨站请求

最简单的检查是否应用存在CSRF缺陷的办法是，检查是否每一个link或form为每一个用户包含了不可预测的标记（unpredictable token）。若是没有这个不可预测标记，攻击者就能够构造恶意请求。

注意session cookie、源IP地址或其余自动产生并被浏览器发出的标记并不属于不可预测标记。由于这些信息在伪造请求中仍然存在（被浏览器自动生成发出）。

一个CSRF漏洞测试工具：

使用帮助：

https://www.owasp.org/index.php/CSRFTester

如何避免伪造跨站请求

阻止CSRF的办法是，在每个请求（body或URL）中包括不可预测的标记。标记至少应该是对每一个用户的每一个session是不一样的，也能够是每一个请求中不一样。

优先选择在隐藏字段（hidden field）中传递这些标记。这样这些值就会在请求体（body of the request）中传递，避免暴露在URL中。

也能够在URL中传递，但这种方法的风险在于这些值可能由于暴露在URL中而被攻击者获取。

OWASP的 CSRF Guardcan能够用来在Java EE、.NET或者PHP应用中包含这些标记：

https://www.owasp.org/index.php/CSRFGuard

OWASP的ESAPI包括了产生和验证这些标记的API。

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/latest/org/owasp/esapi/HTTPUtilities.html

更详细的讨论

跨站请求伪造，也被称成为“one click attack”或者session riding，一般缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与XSS很是不一样，而且攻击方式几乎相左。XSS利用站点内的信任用户，而CSRF则经过假装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比，CSRF攻击每每不大流行（所以对其进行防范的资源也至关稀少）和难以防范，因此被认为比XSS更具危险性。

CSRF攻击经过在受权用户访问的页面中包含连接或者脚本的方式工做。例如：一个网站用户Bob可能正在浏览聊天论坛，而同时另外一个用户Alice也在此论坛中，而且后刚刚发布了一个具备Bob银行连接的图片消息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的连接，并将此连接做为图片tag。若是Bob的银行在cookie中保存他的受权信息，而且此cookie没有过时，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob赞成的状况下便受权了此次事务。

CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。在上面银行示例中的代理人是Bob的web浏览器，它被混淆后误将Bob的受权直接交给了Alice使用。

下面是CSRF的常见特性：

l 依靠用户标识危害网站

l 利用网站对用户标识的信任

l 欺骗用户的浏览器发送HTTP请求给目标站点

风险在于那些经过基于受信任的输入form和对特定行为无需受权的已认证的用户来执行某些行为的web应用。已经经过被保存在用户浏览器中的cookie进行认证的用户将在彻底无知的状况下发送HTTP请求到那个信任他的站点，进而进行用户不肯作的行为。

使用图片的CSRF攻击经常出如今网络论坛中，由于那里容许用户发布图片而不能使用JavaScript。

防范措施

对于web站点，将持久化的受权方法（例如cookie或者HTTP受权）切换为瞬时的受权方法（在每一个form中提供隐藏field），这将帮助网站防止这些攻击。一种相似的方式是在form中包含秘密信息、用户指定的代号做为cookie以外的验证。

另外一个可选的方法是“双提交”cookie。此方法只工做于Ajax请求，但它可以做为无需改变大量form的全局修正方法。若是某个受权的cookie在form. post以前正被JavaScript代码读取，那么限制跨域规则将被应用。若是服务器须要在Post请求体或者URL中包含受权cookie的请求，那么这个请求必须来自于受信任的域，由于其它域是不能从信任域读取cookie的。

与一般的信任想法相反，使用Post代替Get方法并不能提供卓有成效的保护。由于JavaScript能使用伪造的POST请求。尽管如此，那些致使对安全产生“反作用”的请求应该总使用Post方式发送。Post方式不会在web服务器和代理服务器日志中留下数据尾巴，然而Get方式却会留下数据尾巴。

尽管CSRF是web应用的基本问题，而不是用户的问题，但用户可以在缺少安全设计的网站上保护他们的账户：经过在浏览其它站点前登出站点或者在浏览器会话结束后清理浏览器的cookie。

影响CSRF的因素

CSRF攻击依赖下面的假定：

l 攻击者了解受害者所在的站点

l 攻击者的目标站点具备持久化受权cookie或者受害者具备当前会话cookie

l 目标站点没有对用户在网站行为的第二受权

防范CSRF漏洞——测试篇

CSRF（Cross Site Request Forgey）跨站点伪造请求，是排在OWASP Top10第5位的漏洞，它迫使已被认证的用户在Web系统上执行其所不欲的操做。这种攻击依赖于如下：

1） Web浏览器对会话相关信息的处理方式（如cookie或Http认证信息）

　　2）攻击者对正确的Web系统的URL的了解；

　　3）应用会话管理仅依赖于浏览器所了解的信息；

　　4）一些HTML的tag会致使对http(s)资源的直接访问其中，前3点是确认系统是否存在该漏洞的主要前提，第4点则是用来帮助攻击者利用该漏洞的。

　　第1点：浏览器自动发送用于识别用户会话的信息，假设site是一个Web应用站点，victim是一个已经在该系统上通过认证的用户。在server的响应中，site发送一个带有表明victim身份的cookie给victim，原则上，一旦浏览器接收到了服务器发送的cookie，就会在后面对站点的访问中都带上这个cookie；

　　第2点：若是应用在URL中没有使用会话相关的信息，那就意味着应用的URL，它们的参数，相应的值能够被识别。

　　第3点：是指诸如cookie、或者是基于http的认证信息，存放在浏览器中后，就会包含在后面的每次请求中。

　　下面，咱们用Get方法在作个例子，若是用户已经经过了认证，那么在他作下一次请求时，请求数据中会自动加上cookie

　　GET请求通常会有多种缘由产生，

　　* 用户真正在访问Web系统；

　　* 用户在访问地址栏中切实敲入了URL；

　　* 用户点击了一个链接指向了这个URL；

　　这些调用对于系统来讲是没法区别的，特别的，第三种方式相对来讲是极为危险的，有不少种方法能够用来仿造链接的真实属性，链接能够被嵌入到一封邮件中，或者在某个恶意网站上，看上去这个链接好像是在访问另外一个网站，而事实上倒是被引到了Web系统的访问上。若是用户点击了链接，因为它已经被系统认证经过了，浏览器就会对系统提交一个待用认证信息的GET请求。这就在系统上完成了一个操做（尽管这个操做不是用户自己所指望作的）。

攻击者还能够经过Web的一些标记，注入img来达到这个目的。举个例子，假设攻击者发给用户一封邮件，引诱用户访问了一个URL，而这个URL的页面含有下面的HTML：

　　那么用户在点击这个URL时，浏览器将会作什么呢，它将会尝试显示一个宽度为0的图片，而事实上这是访问了www.company.example/action，显然若是浏览器并无阻断下载img的图片，那么该动做就会执行了。

　　该问题的存在是基于如下一些事实：

　　* 有一些HTML的tags可能会执行一些脚本（如img）

　　* 浏览器自己并不能识别img这个tag里的值是不是真实合法的图片

　　* 无论图片是不是在网站本地或是其余网站，图片都会被下载

　　举个例子：

　　假设用户要登陆到某个防火墙web管理系统，登陆时，用户必须对系统进行身份验证，因此用户的会话信息会保存在cookie中。假设咱们的防火墙管理系统容许认证过的用户根据防火墙规则的排号来删除规则（甚至容许用户输入“*”来删除全部的规则），那么下一步显示的就是删除页面，假定表单下面就会提交一个GET请求，是以以下的格式：

　　https://[target]/fwmgt/delete?rule=1

　　或https://[target]/fwmgt/delete?rule=*

　　咱们举的例子很简单，仅仅是为了说明CSRF的存在。

　　那么，若是用户输入了“*”，而后按取了Delete键，那么就提交了以下的GET请求，

　　https://www.company.example/fwmgt/delete?rule=*

　　同时就删除了全部的防火墙规则。

显然，若是用户直接在地址栏中输入https://[target]/fwmgt/delete?rule=*，或者经过某个连接转接到这个url，或者如上面所说，把连接隐藏在img这个tag后面，诸如此种方法，若是用户在点击这个链接的时候，已经登陆进了防火墙管理系统，显然这个访问就能成功奏效，从而达到了删除全部规则的目的。

　　让咱们想象一下，若是这样的攻击用于一些敏感系统，竞拍系统，或者是银行转帐等等，所形成的后果将会多大。

　　应对方法：

　　对于用户来讲，因为CSRF漏洞极为广泛，因此在咱们的平常使用中要注意如下几点：

　　* 保证系统使用完就注销登陆的习惯；

　　* 不要使用浏览器的保存用户名/密码的功能，不要使用网站的“记住我”功能

　　* 不要使用同一个浏览器浏览普通网页和你的关键性Web系统

　　对于开发人员来讲，如上所述，因为将会话相关的信息放入了URL才形成了上述的问题，那么若是咱们在URL层面增长会话特定的信息，那么对攻击者来讲就增长了了解URL结构的难度。另外，咱们还能够尽量的使用POST，而不是GET；尽量多的增长一些诸如“你肯定要这样作吗？”的页面等……

　　说到这，想必你们都已明白CSRF是什么了，下面咱们来看下针对这个漏洞，做为测试人员该如何去测试。

　　通常的测试用例应该以下构建：

　　1. 假设u是须要被测试的URL，例如u =http://www.example.com/action；

　　2. 构建一个包含了访问上述URL信息的html页面；

　　3. 确保合法用户已经登陆了系统；

　　4. 诱使该用户在本身不知情的状况下访问上述URL；

　　5. 确认是否执行了该操做。