同源策略以及cookie安全策略
1、引言
跨站点请求伪造(Cross—Site Request Forgery)．以下简称CSRF。是一种广泛存在的网站漏洞。Gmail、YouTube等著名网站都有过CSRF漏洞．甚至包括“ING DIRECT”这样的荚国第四大储蓄银行的金融机构网站。2009年3月著名 网络安全 机构SANS与MITRE结合来自全球超过30个软件工作者及安全专家，将CSRF列为最危险的25个编程错误之一。
2、现有的Web安全缺陷
2．1 Web安全策略
与CSRF有关的主要有三个Web安全策略：同源策略、Cookie安全策略和Flash安全策略。
2．1．1同源策略
同源指的是：同协议，同域名和同端口。同源策略，简单地说就是要求动态内容(例如，JavaScript或者VBScript)只能读取或者修改与之同源的那些HTTP应答和Cookie．而不能读取来自不同源的内容。浏览器的同源策路限制了脚本只能访问同源下的资源。
同源策略仅仅阻止了脚本读取来自其他站点的内容．但是却没有防止脚本向其他站点发出请求。因为CSRF攻击是由于某些请求被发出，而引起在服务器端执行了某些动作所引起的，所以同源策略无法防止CSRF攻击。
2．1．2 Cookie安全策略
RFC2109定义了Cookie的安全策略。服务器设置Cookie值并为Cookie设置安全属性。Cookie的安全属性包括了Domain、Path、Secure、Expires、MaxAge和HttpOnly等。Cookie安全策略类似于同源策略并且要比同源策略更安全一些，但是利用脚本，可以把Cookie的安全级别降低．甚至Cookie的path属性可以被完全绕过。如果一位攻击者可以突破或绕过两源策略的话，就可以通过DOM的变量document．cookie轻松读取Cookie。
2．1．3 Flash安全策略
默认时，Flash的安全策略与同源策略非常类似，来自于某个域的Flash应用只可以读取来自该域的响应。但是Flash的安全策略并不被同源策略限制．Adobe公司定义了F1ash的跨域策略，该策略通常定义在一个名为crossdomain．xml的策略文件中。该文件定义了哪些域可以和当前域通信。错误的配置文件可能导致兀ash突破同源策略。导致受到迸一步的攻击。安全研究人员曾经对500个顶级网站进行了分析．发现其中有143个站点使用了crossdomain．xml策略文件。而在这143个站点中。又有47个站点对来自第三方站点的连接完全接受，这可能导致CSRF 漏洞 。
2．2 Web认证方式和 浏览器 的安全缺陷
现在的Web应用程序几乎都是使用Cookie来识别用户身份以及保存会话状态。浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie，当一个用户完成身份验证之后．浏览器得到一个标识用户身份的Cookie，只要不退出或关闭浏览器。以后访问相同网站下的页面的时候，对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己，用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时，该请求也会带上当前网站的Cookie。这种认证方式，称之为隐式认证。
不同浏览器对于Cookie的处理不尽相同，Internet Explorer默认阻止向第三方发送当前的Cookie(见213节)，而Firefox和Chrome则默认没有限制。
现在很多用户上网使用多窗口或多标签页浏览器，例如傲游、Firefox、Opera等。这些浏览器在方便用户的同时也增大了风险，因为它们只有一个进程运行，Cookie在各个窗121或标签页之问是共享的。
除了Cookie认证方式之外，其他Web认证机制也面临同样的问题。比如HTTP基本认证，用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接．浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。
2．3 P3P的副作用
Internet Explorer在处理Cookie时，还遵守P3P(Platform forPrivaey Preferenees)规范。P3P是W3C制定的一项关于Cookie的隐私保护标准，要求网站向用户表明它对用户隐私的处理。比如将收集哪些信息。信息做何用途等。如果该站点的信息收集行为同用户设定的标准相符，则两者之闻关于个人隐私信息的协定就可以自动地缔结，而用户可毫无阻碍地浏览该站点；如果不符，浏览器会提醒用户，由用户决定是否对自己制定的个人隐私策略作出修改以进入该网站，双方最终通过一个双向的选择达成用户个人隐私策略。
P3P策略产生了一个副作用：如果一个网站设置了有效的P3P策略，Internet Explorer允许第三方到它的Web请求自动带上Cookie。网站可能遭到CSRF攻击；如果一个网站没有设置P3P策略或者P3P策略无效，第三方到它的Web请求不会带有该网站的Cookie，反而免受CSRF攻击
3、CSRF攻击的原理
网站是通过隐式认证认证用户时，只要不关闭浏览器或者退出，以后访问相同网站时，浏览器会自动在请求中附带上认证信息。如果浏览器被其它网页控制请求了这个网站的URL，可能会执行一些用户不希望的功能。
下面用例子来说明：
假设某个网站（example．com）保存了用户的电子邮件地址信息．并且通过这个邮箱地址实现密码恢复等功能。网站仅采用了Cookie的隐式认证方式来验证用户．用户在验证登录后可以用如下这个URL来更改自己的邮件地址设置：http://www.2cto.com /setemail=邮件地址
那么攻击者只要创建一个HTML页面包含以下代码：
< IMG src=“ http://www.2cto.com /setemail = 新邮件地址”>
当已经登录过example．com的用户访问这个页面的时候，浏览器就会向example．com发出请求改变用户的邮箱地址。
对于所有使用隐式的认证方式并且没有采取针对CSRF攻击的自我保护措施的网站，几乎都可能存在CSRF漏洞。
4、CSRF与XSS比较
Cross—Site Scripting Cxssl允许攻击者将恶意代码注入到受害网站的网页上，其他使用者在观看网页时就会受到影响。这类攻击通常包含了HTML以及客户端脚本语言。
CSRF与之相比区别在于：XSS攻击需要借助脚本语言，CSRF攻击则未必需要脚本语言：XSS需要受害站点接受用户输人来保存恶意代码。而CSRF攻击可能从第三方网站发起；XSS产生的主要原因是对用户输入没有正确过滤．CSRF产生的主要原因是采用了隐式的认证方式。如果一个网站存在XSS漏洞。那么它很大可能也存在CSRF漏洞。即使一个网站能够完美地坊御XsS漏洞，却未必能够防御CSRF。
另外，CSRF与XSS也不是截然分开的，一个攻击可能既是CSRF攻击。又是XSS攻击。
5．防范CSRF攻击
为了防范CSRF攻击，理论上可以要求对每个发送至该站点的请求都要显式的认证来消除威胁。比如重新输入用户名和口令。但实际上这会导致严重的易用性问题。所以，提出的防范措施既要易于实行，又不能改变现有的Web程序模式和用户习惯，不能显著降低用户体验。
5．1服务器端的防范措施
(1)对于网站所有接受用户输入的内容进行严格的过滤。这条措施不止针对CSRF漏洞，而主要是减少XSS漏洞的可能性。而一个有XSS漏洞的网站，很难保证它对CSRF是安全的。这条措施是其它安全措施的基础。
(2)GET方法只用于从服务器端读取数据，POST方法用于向服务器端提交或者修改数据。仅使用POST方法提交和修改数据不能防范CSRF攻击，但是会增加攻击的难度。避免攻击者简单地使用< IMG >等标签就能通过GET方法进行CSRF攻击。
同时，这样做也符合RFC2616推荐的Web规范。
(3)在所有POST方法提交的数据中提供一个不可预测的参数，比如一个随机数。或者一个根据时间计算的HASH值。并且在Cookie中也同样保存这个参数。把这个参数嵌入标签保存在FORM表单中，当浏览器提交POST请求到服务器端时．从POST数据中取出这个参数并且和Cook．ie中的值做比较，如果两个值相等则认为请求有效，不相等则拒绝。根据同源策略和Cookie的安全策略，第三方网页是无法取得Cookie中的参数值的．所以它不能构造出相同随机参数的POST请求。
另外，为了保证一个用户同时打开多个表单页面。所有页面都能正常工作，在一次会话的有效期内。只使用同一个随机参数。也就是说，在会话初始化的时候生成一个随机参数，在以后的页面和Cookie中，都使用这个参数。直到会话结束，新的会话开始时，才生成新的参数，否则会只有用户最后一次打开的页面才能正常提交POST请求．多标签或多窗口浏览器会不能正常工作。
(4)在关键的服务器端远程调用动作之前，增加人机交互环节。例如CAPTCHA人机区分识别程序㈣(典型应用如图片验证码)。
(5)利用Cookie安全策略中的安全属性，但是不要完全依赖Cookie安全策略中的安全属性，只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。
(6)正确配置网站针对Flash的跨域策略文件。严格限制跨域、跨站的请求。
5．2客户端的防范措施
(1)保持浏览器更新，尤其是安全补丁，包括浏览器的Flash插件等的更新。同时也要留意操作系统、杀毒、防火墙等软件的更新。
(2)访问敏感网站(比如信用卡、网上银行等)后，主动清理历史记录、cookie记录、表单记录、密码记录，并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。
跨站点请求伪造(Cross—Site Request Forgery)．以下简称CSRF。是一种广泛存在的网站漏洞。Gmail、YouTube等著名网站都有过CSRF漏洞．甚至包括“ING DIRECT”这样的荚国第四大储蓄银行的金融机构网站。2009年3月著名 网络安全 机构SANS与MITRE结合来自全球超过30个软件工作者及安全专家，将CSRF列为最危险的25个编程错误之一。
2、现有的Web安全缺陷
2．1 Web安全策略
与CSRF有关的主要有三个Web安全策略：同源策略、Cookie安全策略和Flash安全策略。
2．1．1同源策略
同源指的是：同协议，同域名和同端口。同源策略，简单地说就是要求动态内容(例如，JavaScript或者VBScript)只能读取或者修改与之同源的那些HTTP应答和Cookie．而不能读取来自不同源的内容。浏览器的同源策路限制了脚本只能访问同源下的资源。
同源策略仅仅阻止了脚本读取来自其他站点的内容．但是却没有防止脚本向其他站点发出请求。因为CSRF攻击是由于某些请求被发出，而引起在服务器端执行了某些动作所引起的，所以同源策略无法防止CSRF攻击。
2．1．2 Cookie安全策略
RFC2109定义了Cookie的安全策略。服务器设置Cookie值并为Cookie设置安全属性。Cookie的安全属性包括了Domain、Path、Secure、Expires、MaxAge和HttpOnly等。Cookie安全策略类似于同源策略并且要比同源策略更安全一些，但是利用脚本，可以把Cookie的安全级别降低．甚至Cookie的path属性可以被完全绕过。如果一位攻击者可以突破或绕过两源策略的话，就可以通过DOM的变量document．cookie轻松读取Cookie。
2．1．3 Flash安全策略
默认时，Flash的安全策略与同源策略非常类似，来自于某个域的Flash应用只可以读取来自该域的响应。但是Flash的安全策略并不被同源策略限制．Adobe公司定义了F1ash的跨域策略，该策略通常定义在一个名为crossdomain．xml的策略文件中。该文件定义了哪些域可以和当前域通信。错误的配置文件可能导致兀ash突破同源策略。导致受到迸一步的攻击。安全研究人员曾经对500个顶级网站进行了分析．发现其中有143个站点使用了crossdomain．xml策略文件。而在这143个站点中。又有47个站点对来自第三方站点的连接完全接受，这可能导致CSRF 漏洞 。
2．2 Web认证方式和 浏览器 的安全缺陷
现在的Web应用程序几乎都是使用Cookie来识别用户身份以及保存会话状态。浏览器在最初加入Cookie功能时并没有考虑安全因素。假设一个网站使用了Cookie，当一个用户完成身份验证之后．浏览器得到一个标识用户身份的Cookie，只要不退出或关闭浏览器。以后访问相同网站下的页面的时候，对每一个请求浏览器都会“智能”地主动附带上该网站的Cookie来标识自己，用户不需要重新认证就可以被网站识别。当第三方WEB页面产生了指向当前网站域下的请求时，该请求也会带上当前网站的Cookie。这种认证方式，称之为隐式认证。
不同浏览器对于Cookie的处理不尽相同，Internet Explorer默认阻止向第三方发送当前的Cookie(见213节)，而Firefox和Chrome则默认没有限制。
现在很多用户上网使用多窗口或多标签页浏览器，例如傲游、Firefox、Opera等。这些浏览器在方便用户的同时也增大了风险，因为它们只有一个进程运行，Cookie在各个窗121或标签页之问是共享的。
除了Cookie认证方式之外，其他Web认证机制也面临同样的问题。比如HTTP基本认证，用户通过认证后。浏览器仍会“智能”地把用户名和口令附加到之后第三方发给站点的请求中。即使网站使用了安全套接字(SSL)来加密连接．浏览器也会”智能“地自动把SSL认证信息加到第三方发给站点的请求中。
2．3 P3P的副作用
Internet Explorer在处理Cookie时，还遵守P3P(Platform forPrivaey Preferenees)规范。P3P是W3C制定的一项关于Cookie的隐私保护标准，要求网站向用户表明它对用户隐私的处理。比如将收集哪些信息。信息做何用途等。如果该站点的信息收集行为同用户设定的标准相符，则两者之闻关于个人隐私信息的协定就可以自动地缔结，而用户可毫无阻碍地浏览该站点；如果不符，浏览器会提醒用户，由用户决定是否对自己制定的个人隐私策略作出修改以进入该网站，双方最终通过一个双向的选择达成用户个人隐私策略。
P3P策略产生了一个副作用：如果一个网站设置了有效的P3P策略，Internet Explorer允许第三方到它的Web请求自动带上Cookie。网站可能遭到CSRF攻击；如果一个网站没有设置P3P策略或者P3P策略无效，第三方到它的Web请求不会带有该网站的Cookie，反而免受CSRF攻击
3、CSRF攻击的原理
网站是通过隐式认证认证用户时，只要不关闭浏览器或者退出，以后访问相同网站时，浏览器会自动在请求中附带上认证信息。如果浏览器被其它网页控制请求了这个网站的URL，可能会执行一些用户不希望的功能。
下面用例子来说明：
假设某个网站（example．com）保存了用户的电子邮件地址信息．并且通过这个邮箱地址实现密码恢复等功能。网站仅采用了Cookie的隐式认证方式来验证用户．用户在验证登录后可以用如下这个URL来更改自己的邮件地址设置：http://www.2cto.com /setemail=邮件地址
那么攻击者只要创建一个HTML页面包含以下代码：
< IMG src=“ http://www.2cto.com /setemail = 新邮件地址”>
当已经登录过example．com的用户访问这个页面的时候，浏览器就会向example．com发出请求改变用户的邮箱地址。
对于所有使用隐式的认证方式并且没有采取针对CSRF攻击的自我保护措施的网站，几乎都可能存在CSRF漏洞。
4、CSRF与XSS比较
Cross—Site Scripting Cxssl允许攻击者将恶意代码注入到受害网站的网页上，其他使用者在观看网页时就会受到影响。这类攻击通常包含了HTML以及客户端脚本语言。
CSRF与之相比区别在于：XSS攻击需要借助脚本语言，CSRF攻击则未必需要脚本语言：XSS需要受害站点接受用户输人来保存恶意代码。而CSRF攻击可能从第三方网站发起；XSS产生的主要原因是对用户输入没有正确过滤．CSRF产生的主要原因是采用了隐式的认证方式。如果一个网站存在XSS漏洞。那么它很大可能也存在CSRF漏洞。即使一个网站能够完美地坊御XsS漏洞，却未必能够防御CSRF。
另外，CSRF与XSS也不是截然分开的，一个攻击可能既是CSRF攻击。又是XSS攻击。
5．防范CSRF攻击
为了防范CSRF攻击，理论上可以要求对每个发送至该站点的请求都要显式的认证来消除威胁。比如重新输入用户名和口令。但实际上这会导致严重的易用性问题。所以，提出的防范措施既要易于实行，又不能改变现有的Web程序模式和用户习惯，不能显著降低用户体验。
5．1服务器端的防范措施
(1)对于网站所有接受用户输入的内容进行严格的过滤。这条措施不止针对CSRF漏洞，而主要是减少XSS漏洞的可能性。而一个有XSS漏洞的网站，很难保证它对CSRF是安全的。这条措施是其它安全措施的基础。
(2)GET方法只用于从服务器端读取数据，POST方法用于向服务器端提交或者修改数据。仅使用POST方法提交和修改数据不能防范CSRF攻击，但是会增加攻击的难度。避免攻击者简单地使用< IMG >等标签就能通过GET方法进行CSRF攻击。
同时，这样做也符合RFC2616推荐的Web规范。
(3)在所有POST方法提交的数据中提供一个不可预测的参数，比如一个随机数。或者一个根据时间计算的HASH值。并且在Cookie中也同样保存这个参数。把这个参数嵌入标签保存在FORM表单中，当浏览器提交POST请求到服务器端时．从POST数据中取出这个参数并且和Cook．ie中的值做比较，如果两个值相等则认为请求有效，不相等则拒绝。根据同源策略和Cookie的安全策略，第三方网页是无法取得Cookie中的参数值的．所以它不能构造出相同随机参数的POST请求。
另外，为了保证一个用户同时打开多个表单页面。所有页面都能正常工作，在一次会话的有效期内。只使用同一个随机参数。也就是说，在会话初始化的时候生成一个随机参数，在以后的页面和Cookie中，都使用这个参数。直到会话结束，新的会话开始时，才生成新的参数，否则会只有用户最后一次打开的页面才能正常提交POST请求．多标签或多窗口浏览器会不能正常工作。
(4)在关键的服务器端远程调用动作之前，增加人机交互环节。例如CAPTCHA人机区分识别程序㈣(典型应用如图片验证码)。
(5)利用Cookie安全策略中的安全属性，但是不要完全依赖Cookie安全策略中的安全属性，只信任同源策略，并围绕同源策略来打造Web应用程序的安全性。
(6)正确配置网站针对Flash的跨域策略文件。严格限制跨域、跨站的请求。
5．2客户端的防范措施
(1)保持浏览器更新，尤其是安全补丁，包括浏览器的Flash插件等的更新。同时也要留意操作系统、杀毒、防火墙等软件的更新。
(2)访问敏感网站(比如信用卡、网上银行等)后，主动清理历史记录、cookie记录、表单记录、密码记录，并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。
(3)推荐使用某些带有“隐私浏览”功能的浏览器，比如Safail。“隐私浏览”功能可以让用户在上网时不会留下任何痕迹。浏览器不会存储Cookie和其它任何资料．从而CSRF也拿不到有用的信息。IE 8把它叫做“InPfivate浏览”，Chrome称作“Incognito模式”。