深切探讨:反向署理的攻击面 (下) | 申博官网
登录
  • 欢迎进入申博官网!
  • 如果您觉得申博官网对你有帮助,那么赶紧使用Ctrl+D 收藏申博官网并分享出去吧
  • 这里是申博官方网!
  • 申博官网是菲律宾sunbet官网品牌平台!
  • 申博开户专业品牌平台!

深切探讨:反向署理的攻击面 (下)

申博_安全预警 申博 169次浏览 已收录 0个评论

AFL源码分析笔记(一)

0x00 前言 总结师傅们笔记,主要源码分析。 0x01 代码覆盖率 代码覆盖率是fuzz中基本概念,先了解清这个概念后面的插装编译等概念才好理解。 代码覆盖率是一种度量代码的覆盖程度的方式,也就是指源代码中的某行代码是否已执行;对二进制

让我们接着上节的内容,继承讨论。发起读者先浏览第一局部,这将有助于明白本节的内容。

服务端进击

要求毛病路由

例子2

这是关于Nginx的一个“bug”,正确的说它只是Nignx一样平常事情致使的(因而不会被修复)。

起首,服务器设置装备摆设的划定规矩为location /to_app,即/to_app是作为背面增加字符的前缀。因而,/to_app,/to_app/,/to_app_anything(包孕特别标记)都可以也许经由过程该划定规矩。而且,/to_app背面的字符将被提取并与proxy_pass团结(剖析)起来。
Nginx处置惩罚完/to_app_anything后,其转发(到后端服务器)的要求花样为http://server/any_path/_anything

location /to_app {
proxy_pass http://server/any_path/;
}

若是将这些特征连系起来,可以也许发明我们可以也许遍历后端服务器的一切地位。只需发送如许的要求:

GET /to_app../other_path HTTP/1.1

诠释:起首/to_app与Nginx划定规矩相匹配,然后Nginx提掏出../other_path,再与proxy_pass/any_path/相连系,终究转发的要求为:http://server/any_path/../other_path。当后端服务器剖析终了后,我们就可以也许进入想要的目次。

例子3

在上篇文章开首,我已引见了反向署理服务器会依据主机头来转发要求至后端。

这里我运用Haproxy来举个例子。我将Haproxy设置装备摆设为一切主机头为example1的要求都将转发至名为example1_backend192.168.78.1:9999的后端服务器。

frontend http-in
acl host_example1 hdr(host) -i example1.com
use_backend example1_backend if host_example1
backend example1_backend
server server1 192.168.78.1:9999 maxconn 32

关于如许的设置装备摆设,进击者好像没法再接见后端的其他服务器?实在不然,进击者可以也许随意马虎突破防线。因为Haproxy 不支撑Absolute URI(上篇文章中引见过了),然则大局部web服务器都支撑此协定。当Haproxy 收到包罗Absolute URI的要求时,它不会对Absolute URI做任何处置惩罚,直接转发至后端。因而,我们可以也许发送以下要求来接见其他后端服务器。

GET http://unsafe-value/path/ HTTP/1.1
Host: example1.com

那末,我们可以也许经由过程反向署理来接见其后端的恣意服务器?实在在大多数状况下(Nginx, Haproxy, Varnish),这其实不能轻松完成,然则Apache(某些版本)则可以也许。Apache从ProxyPass“剖析”提取主机值,因而我们可以也许发送相似GET @evil.com HTTP/1.1的要求,Apache将其视为http://backend_server@evil.com,然后要求evil.com(你晓得的,这可以也许致使SSRF进击)。这里有一个此类进击的例子。

客户端进击

实在你再回过甚细想偏向署理的特征,你会发明只要与相应相干,就会有潜伏的客户端进击向量。因为浏览器在发送要求前一样平常会做一些处置惩罚,因而这类进击有一些分外的限定,这将致使服务器会有非预期的显示。

浏览器处置惩罚

在一次客户端进击中,进击者须要强迫受害者浏览器发送一个特别的要求,然后服务器做出相应。然则,浏览器会遵照一些范例来处置惩罚途径,然后再发送要求。浏览器会剖析该URL(比方扬弃fragment局部),对某些须要的标记举行URL编码处置惩罚(也许不会),然后在使途径变得范例化。因而,我们要想实行这类进击,我们只能发送一个“有用”的要求。该要求必需相符这三个组件(浏览器,反向署理,后端服务器)。

固然,分歧浏览器的完成(要求)存在差别,再加上一些特征上的区分,可以也许使我们找到一个相符点:

  • 比方,Chrome和IE不会解码%2f,因而它们将纰谬/path/anything/..%2f../如许的途径做范例化处置惩罚。
  • 在范例化处置惩罚之前,老版本的Firefox不做URL解码,但现在它和Chrome有相似的事情体式格局。
  • Safari纰谬途径做URL解码处置惩罚,因而我们可以也许强迫(浏览器)一成不变地发送/path/%2e%2e/another_path/
  • 提及IE,它照样自始自终的奇异。若是主机头为当地地点,那末它不会对途径做任何处置惩罚。

滥用标头修正功用

关于反向署理服务器来讲,增加,删除和修正后端要求中的标头是一项基础功用。有些状况在,这比修正后端自身简朴的多。偶然,反向署理会增加一些主要的平安标头。作为进击者的我们,想要运用这些划定规矩来使反向署理服务器做出毛病的相应(经由过程滥用后端地位标头),从而进击其他用户。

如果我们运用Nginx作为署理,Tomcat作为后端。Tomcat默许设置了X-Frame-Options: deny标头,以是浏览器没法将其嵌入frame中。因为某些缘由,Tomcat web运用的一个组件(/iframe_safe/)必需经由过程iframe接见,因而Nginx设置装备摆设中删除X-Frame-Options标头。然则,为了服务器为了提防clickjacking(点击挟制)进击,做了iframe_safe设置:

location /iframe_safe/ {
proxy_pass http://tomcat_server/iframe_safe/;
proxy_hide_header "X-Frame-Options";
}
location / {
proxy_pass http://tomcat_server/;
}

实在,作为进击者的我们可以也许组织相符Nginx的iframe_safe划定规矩,又能被后端Tomcat剖析为完整分歧的(接见)地位:

<iframe src="http://nginx_with_tomcat/iframe_safe/..;/any_other_path">

浏览器不会对其做范例化处置惩罚。这又相符Nignx的iframe_safe划定规矩。Tomcat支撑途径中插进去参数,取/any_other_path。以是在如许的设置装备摆设下,经由过程frame可以也许接见Tomcat的一切地位,这将致使clickjacking(点击挟制)进击。

做一些头脑发散,我们可以也许运用它来滥用其他平安有关的标头(比方:CORS, CSP)。

————————————-

申博网络安全巴士站

申博-网络安全巴士站是一个专注于网络安全、系统安全、互联网安全、信息安全,全新视界的互联网安全新媒体。

————————————-

缓存

缓存是最风趣的进击向量之一,关于种种进击都有很好的开辟潜力。然则在反向署理范畴运用缓存(进击的要领)依然不为人知。近来,与缓存相干的进击愈来愈受存眷了,网上有一些很酷的研讨比方Web缓存诳骗和有用的Web缓存中毒。在本篇文章中我也存眷到了缓存:我想要分析出缓存的种种完成,从而有助于研讨出缓存诳骗和缓存中毒进击的要领。

它是怎样事情的

我将引见一些反向署理中关于缓存的要点,这将资助你明白这类进击。

完成缓存的体式格局很简朴。在某些状况下,一台反向署理服务器会将来自后端的相应存储到缓存中,今后直接挪用缓存而不消接见后端服务器。一些反向署理服务器默许支撑缓存,另一些则要求用户自行设置装备摆设。一样平常来讲,反向署理服务器会运用缓存标记,该标记与要求的主机头值和途径相干联。

反向署理对某个相应缓存与否,它会先搜检要求中的Cache-ControlSet-Cookie标头。反向署理不会对存在Set-Cookie标头的要求做任何缓存,然则关于Cache-Control有些分歧。它会将其视为缓存战略,要求分外的剖析。Cache-control标头框架非常庞杂,然则有基础的功用标记,比方决议是不是缓存,设置缓存时限等。

Cache-control标头情势有下面这些:

Cache-Control: no-cache, no-store, must-revalidate
Cache-Control: public, max-age=31536000

第一个是制止反向署理缓存,第二个相反。Cache-control标头滥用是许可反向署理贮存相应。

大批的web服务器,运用服务器和框架自动且正确地设置Cache-control标头。在大局部状况下,若是web运用的某个剧本运用了session功用,那末该运用会严厉设置Cache-control标头的缓存功用,因而如碰到这类状况,开辟者不须要斟酌(平安)。然则有破例,比方,若是web运用运用它本身的session平安机制,Cache-control标头可能会存在破绽。

进击

反向署理的一个经常使用功用是“主动缓存”(这不是官方辞汇,但可以也许形貌其作用)。在一种状况下(后端严厉限定,完整不许可缓存),管理员没有修正后端,而是修正反向署理划定规矩,修正严厉的Cache-control标头从而开启了缓存相应。这时候,管理员一样平常都邑毛病设置。比方,只缓存相应中某些扩展名(.jpg, .css, .js)或许某个途径(/images/)。

若是是这类状况,进击者可以也许建立相符反向署理划定规矩又被后端误判的途径。

这里照样Nginx+Tomcat的组合。下面这条划定规矩强迫使Nginx缓存Tomcat上/images目次的一切相应。

location /images {
proxy_cache my_cache;
proxy_pass http://tomcat_server;
proxy_cache_valid 200 302 60m;
proxy_ignore_headers Cache-Control Expires;
}

作为进击者,我们可以也许滥用该划定规矩,从而完成web缓存诳骗。只需受害者翻开下面的这个URL(比方运用img)。

<img src="http://nginx_with_tomcat.com/images/..;/index.jsp">

然后受害者的浏览器将发送要求(照顾经认证的cookie)。Nginx发明要求中存在/image,因而直接转发该要求值Tomcat,然后缓存相应(Tomcat->Nginx,此时Cache-Control标头无效)。Tomcat在处置惩罚时将甄别出/index.jsp,因而进击者可以也许强迫Nginx缓存任何页面,进击者仅需变动途径/images/..;/index.jsp从而偷取受害者的敏感数据(比方token->csrf进击)。

这看起来只是一个web缓存诳骗的变种,但实在不然。

让我们来斟酌缓存中毒进击。此类进击依赖于在要求中找到未加密的值(标头),这将显著地影响(从平安角度)接下来的相应,然则在这里,这个相应必需由反向署理服务器缓存,同时Cache-Control标头应该设置为许可。若是我们把一切器械中和起来,我们可以也许找出一些要领来形成缓存中毒进击。

让我们设想一下这个场景。有一台Nuster(基于Haproxy的缓存署理)服务器和一个web运用。这个web运用上的/account/attacker有一处self-XSS破绽(只在进击者本身的账户上触发)。Nuster设置装备摆设了缓存web运用上/img/目次的一切相应。

nuster cache on
nuster rule img ttl 1d if { path_beg /img/ }

进击者仅需组织特别URL/img/..%2faccount/attacker/,Nuster将会运用“主动缓存”划定规矩,这时候web运用返回self-XSS相应(可以也许看到存在/account/attacker/)。这个带有XSS Payload的相应将被Nuster缓存,因而进击者连系XSS与缓存滥用来进击该运用的用户。这就是从self-XSS到一样平常XSS的一种要领。

小结

在本文中,我已展现了种种毛病设置装备摆设状况的进击。详细的案例其实不主要。我只是想给出关于反向署理的一些新的进击面。若是我们想要相识反向署理怎样事情,它是怎样处置惩罚要求和它与后端服务器有何区分,我们(作为进击者)肯定可以也许找到实在的端点或对用户展开更加庞杂的进击。

谈到提防这类进击,我想说这里没有“银弹”(俚语:指具有驱魔功能的兵器),因为至今我们仍没有一致的途径/要求的范例化规范,若是有,我以为可以也许很好的资助防备方。若是你对署理及其限定有肯定的相识,你也可以也许试着去变动设置装备摆设以探讨差别。

因为我愿望可以也许分享出我的实在设法主意,致使这篇文章篇幅太长。尽管如此,我依然跳过了一些“小把戏“”,你可以也许在这里寓目它们。同时,我在Github上分享了我研讨的原始效果。这项研讨至今仍未完成。我在逐一测试其他软件来完美它。

AFL源码分析笔记(一)

0x00 前言 总结师傅们笔记,主要源码分析。 0x01 代码覆盖率 代码覆盖率是fuzz中基本概念,先了解清这个概念后面的插装编译等概念才好理解。 代码覆盖率是一种度量代码的覆盖程度的方式,也就是指源代码中的某行代码是否已执行;对二进制


申博|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明深切探讨:反向署理的攻击面 (下)
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址