BUG赏金 | 我如何绕过领英的开放重定向保护

嗨，大家好，

在这里，我将讨论几个月前在领英（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”的实际有效哈希值，那么才会成功的重定向。

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

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

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

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

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

谢谢阅读！

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

一、首先是存在referer的场景

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

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

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

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

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

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

个人认为根源是在这里：

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

这样既满足了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