此页面不能正确地重定向_BUG赏金 | 我如何绕过领英的开放重定向保护

本文详细介绍了如何发现并尝试绕过LinkedIn的开放重定向安全防护机制。作者通过分析请求包,发现通过篡改`referer`字段为特定的Scheme(如`android-app://com.linkedin.android`)可以成功实现重定向。这一发现揭示了LinkedIn在处理重定向时可能存在潜在的安全隐患,同时也展示了在安全测试中深入理解HTTP请求头和应用行为的重要性。
摘要由CSDN通过智能技术生成

嗨,大家好,

在这里,我将讨论几个月前在领英(Linkedln)中发现的一个不错的漏洞。在进入漏洞之前,让我快速向您介绍开放重定向。

当应用程序以不安全的方式将用户可控制的数据合并到重定向的目标中时,就会出现开放式重定向漏洞。攻击者可以在应用程序内构造一个URL,该URL导致重定向到任意外部域中。容易受攻击的网站链接的示例可能类似于:

http://xyz.com/login.html?vulparam=https://xyz.com/next

在此示例中,“vulparam”参数表示成功登录后,将用户跳转到的位置。如果网站未验证“ vulparam”参数值以确保目标网页是合法并且是自己所期盼的,那么攻击者可以操纵该参数将用户跳转到自己所制作的恶意页面上:

https://xyz.com/login.html?vulparam=http://evil.com

但是绕过Linkedln开放重定向并不是那么容易。易受攻击的网址是

https://www.linkedin.com/lite/external-redirect?url=http://evilzone.org&urlHash=YKI5

Linkedln使用了一些很好的开放重定向保护机制,导致我无法使用一些普通的方式进行绕过,例如

url = .. / evilzone.org
url = ///evilzone.org
url = ///www.linkedln.com@www.evilzone.org/%2f%2e%2e

目前的状况是,仅仅将“url”值更改为任何恶意站点都将无法起作用。仔细观察url中还有一个额外的参数“urlHash”,它看起来像是用户被重定向到的URL的hash值,所以如果“ urlHash”值是“ url”的实际有效哈希值,那么才会成功的重定向。

至此传统的绕过方式并不能成功,因考虑通过对原始请求数据包进行深入分析,查看是否有绕过的可能性

423b98818a5a855c7003f93ae3527cd2.png

可以看到该请求头包含“referer”字段,该字段指向用户所访问的最后一个页面(也就是用户点击链接的那一页),而该页面中并不包含恶意url链接,因此该数据包并不能够完成自己所想要的功能。

那么假如更改referer为自己所设置的domain(其中包含http://evilzone.org),那么便满足之前所需要的恶意url真实存在的要求。于是尝试更改referer字段的值并查看在这里是否起作用,但是失败了~ (这里猜测领英可能不允许一些其他不合法的referer存在)

继续进行尝试,那么既然要referer是合法的,便考虑抓取领英app的请求包,发现其中“referer”字段的值是这种样子的“android-app://com.linkedin.android ”。那么referer字段中使用该值,重新进行重定向的测试,发现成功了

a87f6f6ed732b0762f14e0d2ad314c73.png

成功的重定向,是的,我终于绕过了LinkedIn的开放重定向保护 :)

谢谢阅读!

Emmmm,可能看到这里,都还是处于一个蒙圈的状态,下面进行一些解释。

一、首先是存在referer的场景

当我们直接在浏览器的地址栏中输入一个资源的URL地址时,由于这是一个凭空产生的http请求,并不是从某一个位置跳转过去的,那么这种请求方式是不会包含referer字段的。

78f813fc7b7a50e62111ba34f731911d.png

许多网站中都有其他网站的链接,假如我们通过访问链接,从一个网站跳转到另一个网站,那么在请求头部信息中便会存在referer。

6c7d9117c05ce473289db3ecd58b7175.png

点击跳转后查看,发现存在referer为之前的网址。

1a936d672e7428f7bfe43ad228b6c777.png

二、然后在了解一下在app中是如何跳到指定界面

是使用Scheme协议,Android中的Scheme是一种页面内跳转协议,通过自定义Scheme协议,可以跳转到app中的任何页面。当然app也可以通过Scheme跳转到另一个app页面。暂时了解到这里就够了。

三、最后对为什么更换了referer为android-app://com.linkedin.android,便会成功绕过的一点个人理解,如果不对的话随时欢迎讨论~

个人认为根源是在这里:

当笔者发现android-app被添加的有效列表后,便可以被正常解析。

57f912aec0e151a5013c3f3613fe502a.png

这样既满足了referer是合法的,并且通过app使用Scheme协议可以完成页面的跳转,即跳到攻击者所期待的页面(http://evil.com)在某种程度上也是合法的。当然也存在领英app在这里并没有任何的过滤措施的可能性。

参考链接:

https://www.jianshu.com/p/49b11da1f0a9

https://github.com/snowplow-referer-parser/referer-parser/pull/145#ref-issue-165714112

https://github.com/snowplow-referer-parser/referer-parser/issues/172

https://github.com/snowplow/referer-parser/issues/131

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值