同源策略以及cookie安全策略

本文深入探讨了跨站点请求伪造(CSRF)攻击的原理及其防范措施。介绍了与CSRF相关的Web安全策略,如同源策略、Cookie安全策略等,并对比分析了CSRF与XSS的不同之处。
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记录、表单记录、密码记录,并重启浏览器才访问其他网站。不要在访问敏感网站的同时上其它网站。
 

    (3)推荐使用某些带有“隐私浏览”功能的浏览器,比如Safail。“隐私浏览”功能可以让用户在上网时不会留下任何痕迹。浏览器不会存储Cookie和其它任何资料.从而CSRF也拿不到有用的信息。IE 8把它叫做“InPfivate浏览”,Chrome称作“Incognito模式”。

<think>好的,我现在需要解决用户的问题,关于如何使用InternetGetCookieEx函数获取受同源策略限制的网页Cookie。用户提到同源策略限制,所以首先我需要理解这两个关键点:InternetGetCookieEx的工作原理和同源策略如何影响Cookie的获取。 首先,回忆一下Windows API中的InternetGetCookieEx函数。根据MSDN文档,这个函数用于从指定的URL获取Cookie。函数原型大概是这样的: BOOL InternetGetCookieEx( LPCWSTR lpszURL, LPCWSTR lpszCookieName, LPWSTR lpszCookieData, LPDWORD lpdwSize, DWORD dwFlags, LPVOID lpReserved ); 其中,dwFlags参数可以控制行为,比如使用INTERNET_COOKIE_HTTPONLY来获取HttpOnly的Cookie。但问题是,同源策略(Same-Origin Policy)是浏览器实施的安全策略限制同源的脚本访问彼此的资源,包括Cookie。所以,当用户尝试用InternetGetCookieEx获取跨域的Cookie时,可能会因为同源策略限制而失败。 接下来,我需要确定InternetGetCookieEx是否真的受到同源策略限制。根据我的理解,InternetGetCookieEx属于WinINet API的一部分,而WinINet在实现上可能遵循了部分浏览器安全策略,比如同源策略。例如,如果一个Cookie被设置为仅限于特定的域或路径,那么使用InternetGetCookieEx访问不同域的URL可能无法获取到该Cookie。这种情况下,函数可能返回空或者错误。 用户可能需要绕过同源策略来获取其他源的Cookie,但这样做存在安全隐患,且可能违反浏览器的安全策略。不过,在某些情况下,比如本地应用程序需要访问特定Cookie时,可能需要特定的配置或权限。 可能的解决方案包括: 1. **确保同源条件**:检查目标URL是否与Cookie的域、路径和协议匹配。如果应用在相同源下运行,可能就能成功获取Cookie。例如,如果Cookie属于`http://example.com`,则用该URL调用函数。 2. **调整Cookie属性**:在服务器端设置Cookie时,使用`Set-Cookie`头部的`Domain`和`Path`属性,使其对目标URL可见。例如,设置`Domain=.example.com`允许子域访问。 3. **使用浏览器组件**:通过嵌入WebBrowser控件或使用自动化工具(如Selenium)在浏览器环境中执行脚本,以同源的方式获取Cookie,再传递给外部应用。 4. **提升权限或策略设置**:某些安全策略可能限制Cookie访问,需要调整IE的Internet选项中的安全设置,但这种方法不推荐,可能影响系统安全。 5. **检查第三方Cookie设置**:确保IE或其他相关浏览器允许第三方Cookie,因为同源策略可能阻止跨域Cookie的读取。 接下来,我需要验证这些方案的可行性。例如,第一个方案中,如果Cookie的域和路径正确,InternetGetCookieEx应该能正确获取。但如果跨域,即使设置Domain属性,也可能被同源策略阻止。例如,假设Cookie的域是.example.com,而请求的URL是sub.example.com,可能可以访问,但如果是另一个域如another.com,就无法获取。 关于使用InternetGetCookieEx的具体示例代码,用户可能需要正确的URL和标志。例如,在C++中调用该函数时,传入正确的URL参数,并处理缓冲区大小的问题。 此外,需要注意的陷阱包括:函数返回ERROR_INSUFFICIENT_BUFFER时需要重新分配缓冲区,以及正确处理Unicode字符串。同时,跨域访问可能需要使用INTERNET_COOKIE_THIRD_PARTY标志,但需确认是否有效。 引用方面,可以参考MSDN文档中的InternetGetCookieEx页面,以及关于同源策略的说明。例如,MSDN提到该函数的行为受安全区域和隐私设置的影响[^1],而同源策略的定义可以参考MDN Web文档[^2]。 最后,生成相关问题需要考虑用户可能遇到的后续疑问,比如如何设置Cookie属性、如何处理特定错误代码,或者替代方法等。</think>### 使用`InternetGetCookieEx`获取受同源策略限制Cookie的解决方案 #### 关键问题分析 1. **同源策略限制**:浏览器禁止跨域访问Cookie,`InternetGetCookieEx`作为系统级API,其行为受IE浏览器安全策略影响[^1]。 2. **Cookie作用域**:需确保目标URL与Cookie的`Domain`、`Path`属性完全匹配,否则无法读取。 #### 解决方案 1. **验证Cookie作用域** - 检查Cookie的`Domain`和`Path`是否包含目标URL。 - 示例:若Cookie设置`Domain=.example.com`,则可通过`https://sub.example.com/page`获取。 2. **调整API调用参数** 使用`INTERNET_COOKIE_THIRD_PARTY`标志允许第三方Cookie(需浏览器设置支持): ```cpp DWORD dwFlags = INTERNET_COOKIE_THIRD_PARTY; WCHAR szCookieData[4096]; DWORD dwSize = 4096; InternetGetCookieEx(L"https://target-domain.com", NULL, szCookieData, &dwSize, dwFlags, NULL); ``` 3. **修改IE安全策略**(不推荐) - 进入IE设置 → Internet选项 → 安全 → 自定义级别 → "跨域浏览窗口和框架"设为启用。 - 注意:此操作会降低系统安全性[^1]。 4. **使用浏览器自动化工具** 通过WebBrowser控件或Selenium模拟同源环境获取Cookie: ```python # 示例:使用Selenium获取Cookie from selenium import webdriver driver = webdriver.Chrome() driver.get("https://target-domain.com") cookies = driver.get_cookies() # 可获取同源策略下的所有Cookie ``` #### 错误排查 - **ERROR_NO_MORE_ITEMS (259)**:目标URL无有效Cookie。 - **ERROR_INSUFFICIENT_BUFFER (122)**:缓冲区不足,需扩大`szCookieData`并重试。 #### 引用说明 `InternetGetCookieEx`的行为受IE隐私设置和安全区域策略限制,跨域访问需明确权限[^1]。同源策略的详细定义可参考Web安全文档[^2]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值