跨站点请求伪造(CSRF)

CSRF(Cross Site Request Forgery)跨站点请求伪造:攻击者诱使用户在访问 A 站点的时候点击一个掩盖了目的的链接,该链接能够在 B 站点执行某个操作,从而在用户不知情的情况下完成了一次对 B 站点的修改。

CSRF 实现

Cookie 策略

Cookie 分为 Session Cookie(临时 Cookie) 和 Third-party Cookie(本地 Cookie)。本地 Cookie 有失效时间,在失效时间内都可以使用。临时 Cookie 则在浏览器关闭后立即失效。CSRF 攻击过程中,用户浏览器将上传 Cookie 作为认证信息(无需认证的除外)。如果用户同时正在访问 B 站点,那么就有活跃的临时 Cookie 将被上传。然而,如果用户并未打开 B 站点,但存有未失效的本地 Cookie,根据流量器安全策略的不同(IE 默认禁止在<img>、<iframe>、<script>、<link>等标签中发送本地 Cookie,Firefox 默认允许发送本地 Cookie;默认会拦截本地 Cookie 的浏览器:IE 6/7/8,Safari;默认不拦截本地 Cookie 的浏览器:Firefox 2/3,Opera,Google Chrome,Android),本地 Cookie 可能被上传认证,导致攻击成功。【安全建议:及时清除浏览器数据,及时关闭浏览过的网站】

P3P 头

The Platform for Privacy Preferences,P3P Header 是 W3C 制定的一项关于隐私的标准。如果网站返回给浏览器的 HTTP 头中包含有 P3P 头,则将允许浏览器发送本地 Cookie。在 IE 下即使是<iframe>、<script>等标签也将不再拦截本地 Cookie 的发送。由于 Cookie 是以域和 path 为单位设置的,因此 P3P 头设置后对 Cookie 的影响将扩大到整个域中的所有页面。【安全建议:在 CSRF 的防御中不能依赖于浏览器对第三方 Cookie 的拦截策略,因为如果设置了 P3P 头,则浏览器自身的拦截策略将失效】

GET 请求和 POST 请求

虽然常见的 CSRF 都由发送 GET 请求的方式实现攻击,但 POST 请求也是可以被利用来做 CSRF 攻击的。如果站点没有指定提交数据的请求方式,那么 GET 和 POST 均可发送控制请求。如果只能用 POST 请求,最简单的方法是,在页面中隐含地构造一个 form 表单,然后使用 JavaScript 自动提交这个表单。即,如果 A 站点为攻击者所控制,则只需让链接触发一个由 JavaScript 发送 POST 请求的动作;如果 A 站点非攻击者所能控制,则只需让链接指向一个能用 JavaScript 发送 POST 请求的 X 站点,由 X 站点做媒介,发送恶意请求的时候带上 B 站点的本地/临时Cookie。

Flash CSRF 和 CSRF Worm

Flash 有多种方式能够发起网络请求:POST、getURL、loadVars 等。IE 6/7 中,Flash 发送的网络请求可以带上本地 Cookie,IE 8 起禁用了该功能。

经过精心设计,CSRF 漏洞也可以用于蠕虫攻击——比如传播消息。

CSRF 防御

验证码

优点:简单有效

缺点:用户体验不佳

Referer Check

Referer Check 可被用于检查请求是否来自合法的“源”。常见的互联网应用,页面与页面之间都具有一定的逻辑关系,这种关系使得每个正常请求的 Referer 具有一定规律。检查 Referer 可以有效地防御跨站点的请求伪造。

缺陷:然而服务器并非总是能够提取到 Referer 属性,很多用户处于隐私保护的考虑,限制了 Referer 的发送,某些情况下浏览器也不会发送 Referer(比如 HTTPS 跳转到 HTTP)。

Anti CSRF Token

CSRF 的本质原因是重要操作的所有参数都是可以被攻击者猜测到的。因此 Anti CSRF Token 的原理就是,通过增加一个不可预测的请求参数 Token,来区分合法请求和非法请求,从而拒绝 CSRF。

Token 需要足够随机,而且应该作为一个“秘密”,仅为用户与服务器所共同持有。

实际应用中 Token 可以放在用户的 Session 中或浏览器的 Cookie 中【不建议】。推荐做法是将 Token 存放在页面表单(隐藏的 input 字段)和 Session 中,而且提交操作应该设置为 POST,避免 Token 泄露。切记,不要在 URL 中存放 Token,否则通过 Referer 可以被窃取。

当一个站点同时存在 XSS 和 CSRF 漏洞的情况下情况将变得不容乐观,攻击者可以通过 XSS 漏洞获取 Cookie 和 Token,然后轻易发起 CSRF 攻击。

时间: 2024-12-21 02:33:00

跨站点请求伪造(CSRF)的相关文章

我要学ASP.NET MVC 3.0(十三): MVC 3.0 防止跨站点请求伪造 (CSRF) 攻击

我要学ASP.NET MVC 3.0(十三): MVC 3.0 防止跨站点请求伪造 (CSRF) 攻击 概述      众所周知,ASP.Net MVC程序在浏览器运行时产生了标准的Html标签,包括浏览器要发送的关键数据等内容都在Html内容里面,听起来不错,但是假如我们仿造类似的Html内容,更改里面关键数据,在浏览器运行起来会怎么样呢?好下面我们就做这样一个例子.       CSRF攻击例子 首先我们拿以前做好的person/edit作为例子 先看控制器代码 //初始页面        

跨站点请求伪造(CSRF)总结和防御

什么是CRSF 构建一个地址,比如说是删除某个博客网站博客的链接,然后诱使已经登录过该网站的用户点击恶意链接,可能会导致用户通过自己的手将曾经发布在该网站的博客在不知情的情况下删除了.这种构建恶意链接,假借受害者的手造成损失的攻击方式就叫CSRF-跨站点请求伪造. 浏览器Cookie策略 cookie分类 cookie根据有无设置过期时间分为两种,没有设置过期时间的为Session Cookie(会话cookie),firefoox有标注哪些cookie是会话cookie,这种cookie保存在

[不常用] - CSRF(跨站点请求伪造)

CSRF,Cross Site Request Forgery,即跨站点请求伪造.   这种攻击是指,在用户正常登录系统以后,攻击者诱使用户访问一些非法链接,以执行一些非法操作. 比如:如果删除用户操作(如,yourdomain.com/deluser?id=123)没有经过防范CSRF的处理,那么,假设用户登录系统后,攻击者诱使用户同时访问了攻击者的站点的一个链接(该链接正好为yourdomain.com/deluser?id=123),那么,系统就会在用户不知情的情况下丢失一个用户.    

《白帽子讲WEB安全》学习笔记之第4章 跨站点请求伪造(CSRF)

第4章 跨站点请求伪造(CSRF) 4.1 CSRF简介 CSRF(Cross-site request forgery跨站请求伪造,也被称为"one click attack"或者session riding,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用. CSRF是一种依赖web浏览器的.被混淆过的代理人攻击(deputy attack). 4.2 CSRF进阶 浏览器所持有的Cookie分为两种:一种是"Sesion Cookie",又称"

CSRF(跨站点请求伪造)

引起原因:个人认为 csrf 在 Ajax 盛行的今天来说,倒是方便了,因为它可以在你不知道的情况用你的通过验证用户进行操作,所以也被称为浏览器劫持.如果你已通过某个网站的验证那么你将以你的角色对网站进行操作,比如你是管理员可以添加其它的用户到管理组,但是如果有人构造了添加管理员的链接被管理员点后也会执行相应操作. 解决方法: 修改信息时添加验证码或添加 Session 令牌(ASP.NET中已经提供一个自动防范的方法,就是用页面属性 ViewStateUserKey.在Page_Init方法中

Django中如何防范CSRF跨站点请求伪造***

CSRF概念 CSRF跨站点请求伪造(Cross-Site Request Forgery). ***者盗用了你的身份,以你的名义发送恶意请求,对服务器来说这个请求是完全合法的,但是却完成了***者所期望的一个操作,比如以你的名义发送邮件.发消息,盗取你的账号,添加系统管理员,甚至于购买商品.虚拟货币转账等. CSRF***原理以及过程 用户C打开浏览器,访问受信任网站A,输入用户名和密码请求登录网站A: 2.在用户信息通过验证后,网站A产生Cookie信息并返回给浏览器,此时用户登录网站A成功

跨站点请求伪造

跨站点请求伪造 危害:可能会窃取或操纵客户会话和 cookie,它们可能用于模仿合法用户,从而使黑客能够以该用户身份查看或变更用户记录以及执行事务 可能原因:应用程序使用的认证方法不充分 技术分析:即使是格式正确.有效且一致的请求也可能已在用户不知情的情况下发送.因此,Web 应用程序应检查所有请求以发现其不合法的迹象.此测试的结果指示所扫描的应用程序没有执行此操作.此脆弱性的严重性取决于受影响应用程序的功能.例如,对搜索页面的 CSRF 攻击的严重性低于对转账或概要文件更新页面的 CSRF 攻

跨站请求伪造CSRF原理

跨站请求伪造CSRF原理 CSRF是Cross Site Request Forgery的缩写,CSRF是伪造成合法用户发起请求 先了解下session: 用户登录时服务器端生成一个Session 返回给用户session_id在cookie中 用户下次登录带着有session_id的cookie登录 跨站请求伪造例子 只有session的话,如果有一个网站可以访问所有的cookie,那么就会获取到所有的session,然后带着你的session去访问别的网站. 比如:在一些诱骗性的网站上,可以

CSRF跨站点请求伪造漏洞问题

最近在写php,项目写完后送检发现一个漏洞问题CSRF,强行拖了我一天的时间,沉迷解决问题,茶饭不思,日渐消瘦,时间比较赶,这篇比较糙,凑合看下. 好了废话不多说下面是今天的解决方案. 博主用的是Thinkphp框架,发现这个问题的时候第一件事就是去查下相关资料,发现发现网上说可以通过表单令牌来解决这个问题. 如果不设置表单令牌,很容易导致CSRF(跨站请求伪造).跨站提交表单. 表单令牌是一种非常实用的技术(博主ps:其实鸡肋),它在表单的视图部分生成随机令牌,默认为随机的MD5串,存在hid