| 
色五月第二季
0x00 媒介
这篇著述主要讲面前互联网上get方法被不门径使用带来的一些安全误差。其中要点会讲get请求在账号登陆体系中被糟践的场景和挫折方式。
0x01 Get方法的界说
在客户机和办事器之间进行请求-反馈时，两种最常被用到的方法是：GET 和 POST
GET - 从指定的资源请求数据
POST - 向指定的资源提交要被处理的数据
GET 方法的查询字符串是在 GET 请求的 URL 中发送的，常见的场景是地址栏请乞降超结合。
0x02 Get请求常见于如下场景中
浏览器地址栏中可见，会被别东谈主看到
浏览器历史记载
被云加快的cdn办事商会聚，proxy
被运营商或会聚蛊惑会聚重放
在不安全的会聚环境中被会聚嗅探
用户的储藏夹
http的header的referrer字段中
web办事器日记、应用日记
被搜索引擎爬到，或者被客户端软件不门径会聚
被用户邮件或微信共享出去
各式可能的处所，以致山岗上田园上（一个黑客盗取了你的get请求后，途经一个山岗时，被大灰狼吃掉了，U盘掉在了山岗上）
0x03 Get请求的风险
根据HTTP门径，GET用于信息获取，是安全的和幂等的。安全的意念念是get请求不会让办事端的资源或现象改变。幂等的意念念是不管请求若干次，复返的扫尾皆雷同，皆不会对办事端资源有任何反作用。
是以从被遐想和实际中被使用的场景来看，get请求有如下特质
因为是获取资源的请求，是以会在客户端、缓存端和办事器端等处所到处出现，容易流露被第三方得到
因为是安全和幂等的，是以各时势重放get请求时无须挂念，无须教唆用户。重放post未必浏览器会教唆用户是否确定要重新发送数据
是以get请求的使用应该奉命
不应有增删改的操作
不应包含敏锐信息
当你的杀青不得当别东谈主对你的预期，就可能产生误差，如
秘籍流露，被csrf误差愚弄，账号被盗……
0x04 若你非要用get杀青增删改
会被重放，导致办事端资源现象发生改变
浏览器的重新翻开可能会重放请求，而不会教唆用户
爬虫或安全扫描会重放你的请求
获取到你get请求的各式势力可能会重放此请求，如安全厂商，搜索引擎，奥秘力量（除了山岗上阿谁黑客，因为他还是被大灰狼吃掉了）
get操作的csrf驻守很难实施，因为get莫得防伪造的需求，它的场景不一定勾通你的驻守。referrer信任可能被愚弄，token可能被偷。举个例子，一个塑料盒子，它本就不是被遐想用来存钱的，你若非要用它存钱，并还要加上一把锁，后果坚信不会好。见底下例子：
网站允许用户发表第三方结合、图片等，那么用户构造的csrf请求的referrer是真确域的url，不错绕过referrer的驻守
存在js端的跳转误差跳到第三方，同理不错绕过referrer
Get请求中驻守的token容易被偷，旨趣同上，后头的章节会细讲
常见的场景：一些使用了mvc框架的圭臬，径直用urlrewrite后的url来杀青了增删改等操作
0x06 若你非用get传输敏锐信息
互联网上常见的敏锐信息例如：
秘籍信息
环球可能合计微博id不算秘籍，但一朝你的id和某些操作绑定的手艺，那就算是秘籍了
校验信息 捆绑 调教
https://mp.weixin.qq.com/cgi-bin/home?t=home/index&lang=zh_CN&token=371767643
这是微博公众平台不竭后台的首页，首页url里会包含csrf驻守的token
认证信息
?ticket=*****************
?gsid=******************
许多登录认证如单点登录，绑定第三方账号登录等会用get请求来完成登录
如果你的get请求中包含如上一些信息，那么你的敏锐信息将会被偷被流露，然后你会被搞！！！
0x07 敏锐信息流露例如
秘籍信息流露例如
用户登录微博后，首页的url会含灵验户ID信息。是以timeline上的结合的主东谈主和会过referrer知谈哪些用户探问了它。可能环球皆不会着重，它可能会帮你逮微博马甲、捉奸在网……
比如如下场景：
某天你男友出差，永夜漫漫，你很没趣，写了一篇博客，记载下了盛夏夜中你此刻的激情。喝完咖啡，你正经营上床睡眠了，倏得你又艳羡想知谈我方芳华的文华已被若干东谈主阅读。于是你翻开电脑，登上办事器，去搜检你博客的探问日记，从referrer中你发现，你的男一又友和你的男共事在凌晨少量，皆探问了你发的结合，何况IP雷同。这个手艺，手脚一个须眉汉，你可能要辩论下，应该哭多高声才不会吵到邻居……虽然，你还不错安危我方，他们是一谈在网吧整夜玩游戏
我还也曾用此方法帮东谈主揪出了一些东谈主的微博马甲。惟有你够没趣，你还不错玩些别的，比如在用户翻开的页面上再放上些兴味爱好治病寻医类的告白，如果他点了，你就可能会知谈她闲居爱逛的是不是三里屯的优衣库了。
我不明晰微博的首页地址为何要这么遐想，办事端若要读面前用户id，充足从面前会话中就可读取，而且从安全的角度辩论，也不应该会从url中读取用户id信息。那为什么要涌现用户的id呢…
token信息流露例如
如上图，这是微信公众平台后台不竭员点击了网友发来的信息后的翻开第三方页面的请求，referrer字段中的url中包含了不竭后台的csrf驻守的token
微信公众后台的操作大多是post，csrf的驻守有token和referrer，但在每个页面的get请求中，也会含有这个token。这么的话token很容易被referrer偷，见上图色五月第二季，token还是发给了第三方域了。这么csrf的驻守体系就被放松了
趁便说一句，这个后台是https的，是以咱们的结合也如若https的才会发送referrer。在网上央求个免费的https站点即可
好在这个问题面前没什么危害，不竭后台的csrf驻守是referrer和token皆作念了的，而且用户想给公众号发一个结合需要一些小手段，径直发结合在后台是不行以酿成结合的。
认证信息流露例如——被referrer发到第三方
上图是当今的乌云的厂商用户的搜检误差笃定的临时页面，蓝本的页面是莫得搜检密码的，是不错通过地址栏里阿谁含有auth信息的get请求径直搜检误差笃定的
但某一误差笃定页包含了一个优酷的视频，这个搜检笃定的结合会在优酷的视频页涌现。因为优酷为了告诉用户展示起原，涌现了referrer信息。这么这个误差笃定的临时搜检页面就不错被网友在网上不测撞见了，厂商的误差笃定可能会被提前流露。见下图
笃定可参考 WooYun: 乌云某临时授权搜检结合在某些极小可能性下有流露的可能
然后我想望望这个搜检误差的授权页在网上流露了若干，去百度搜了下
一个月内流露的乌云厂商用户的临时搜检结合的确有十二页之多，我合计应该不行能全是厂商不竭员共享出去的。是以我有了一个揣测，不一定是错的，那即是：乌云的通盘get请求皆已被百度云加快会聚，用来匡助用户进行搜索的seo优化。
0x08 偷最敏锐的信息——认证信息
使用get请求认证的一些场景
单点登陆从sso拿ticket信息，参数名如ticket、auth
网站绑定第三方账号登陆，第四色小说由第三方给的登陆左证
App给内嵌页面请求加上认证信息，参数名如sid、gsid
Xss偷不了httponly的cookie了？
你不错试试偷上头的这些认证信息
Xss能作念的比你联想的要多，它毕竟是个代码实践误差
如果Xss不好找？你还不错试试referrer，它不产生误差，但它是误差的搬运工
起始咱们了解些布景常识，我苟简先容下单点登陆
需求：如果用户还是登陆B站，则自动登陆A站
杀青：用户探问A站，A站把用户跳转到B站，B站考证用户已登陆，给用户一张票，用户拿着票去找A站，A拿着票去B那，考证顺利后放用户进去
下文中将多数出现如下示例站点
A:
B:
例如：用户探问?url=
B站测验A站是白名单域后，然后302跳转到
?ticket=******
然后a.php用ticket参数去B站考证用户正当后，再给用户种认证cookie
偷认证信息的大约进程如下，后头会细讲。总之挫折的见识即是，拿到用户的ticket信息
0x09 How
互联网上常见的几个单点登陆场景，通行证或第三方站给的登陆凭的证使用的方式各有不同，区别该怎样偷
场景一，径直使用单据来作念考证，get型csrf的token和此雷同
?ticket=XXXXXXXXXXXXXXXX
办事端使用此ticket去sso考证此用户身份，然后在本域种认证cookie
偷的念念路：
让咱们构造的页面获取到左证后请求咱们为止的办事器上的资源，这么referrer里就有ticket信息了
偷的几种方式
找能发自界说src的图片的页面去sso取票，带着ticket信息的页面会发起图片请求，图片办事是咱们我方的，咱们不错读到请求中的referrer，referrer中会包含ticket信息
找能发自界说src的iframe的页面，iframe请求中的referre有ticket
找一个有js跳转误差的页面去取票，跳转见识地址是咱们的办事，js的跳转是带上referrer的，读取此请求的referrer，内部包含ticket
如果img和iframe的src值只允许白名单域的url，那就再找一个白名单域的302跳转误差来绕过白名单，302跳转不错传递上个请求的referrer
Xss获取地址栏信息
流露图如下，如下是我画的一个chrome浏览器，地址栏里ticket参数会被包含到底下的一些元素的请求的referrer中
参考案例： WooYun: 微博上你点我发的结合我就不错登上你的微博（web版和app端均可两个误差一并提交）
场景二，当咱们在一个app内翻开其公司产物的一些结合，会被加上认证信息去让用户自动登陆
微博客户端、QQ客户端、微信客户端皆曾有或当今正有此问题
一般会加上参数sid、gsid、key
例子： WooYun: 手机版QQ空间身份身分可被盗用（主动截获用户sid）
例子： WooYun: 聊着聊着我就上了你……的微信（两处皆不错劫捏微信登录的误差）
例子：之前的一个手机qq的误差，找一qq域下论坛发一张图，然后把此页发给手机qq上好友，他点击就会被盗号
偷的几种方式
见场景一的各式方式
用户以致和会过app的共享功能把认证信息共享到邮件或一又友圈。也曾遇过一个案例，一个活动引申页面在app内被翻开后，被app加上了get参数去完成了自动登陆，因为页面要得到用户的一些有关信息。然后这个带着认证参数的引申页面会被用户共享出去，然后别东谈主点击了这个结合，就登陆了共享东谈主的账号
场景三，中间页袭取ticket完成认证，然后用js跳转到咱们的筹画页?ticket=XXXXXXXXXXXXXXXX&url= 此时会种上认证cookie
然后页面会使用js跳转到
location.href=“”;
参考示例：某绑定了微博账号后不错自动登陆的网站
偷的念念路：
因为js的跳转，ticket还是通过referrer发给了a.php了，那咱们惟有让a.php成为咱们为止的页面就不错了，恰恰302跳转不错帮咱们杀青
偷的几种方式
找一个有302跳转误差的页面如b.php，发起单点登陆请求，然后带着ticket信息的b.php会跳转到咱们的办事上。因为js的跳转会带referrer，然后再通过302跳转把referrer传给咱们能为止的页面
Xss获取面前页面referrer
场景四，中间页袭取ticket完成认证，然后用302跳转到咱们的筹画页?ticket=XXXXXXXXXXXXXXXX&url= 此时会种上认证cookie
然后页面会再302跳转到
参考示例：好几个大的互联网网站……
偷的几种方式
前边的一些靠referrer偷的方式皆没法用了……
只可靠xss了，不要小看xss，不要光知谈偷cookie
这种情况是多个302的跳转，跳转旅途如下
请求1：?url=
请求2：?ticket=XXXXXXXXXXXXXXXX&url=
请求3：
偷的念念路：
在xss中，用iframe包含单点登录的请求1，登录跳转后，咱们通过src属性不错读到请求1的url，使用iframe.contentWindow.location.href不错读到跳转终末的请求3的url。但咱们需要的是中间的请求2。是以咱们想，可不行以让它跳到请求2后，不再赓续跳转了，这么咱们通过iframe.contentWindow.location.href就不错读到请求2的url了。这手艺我想起，cookie超长的隔断办事终于不错派上用场了
偷的方式
Xss创建iframe，种超长cookie，让含ticket的302隔断办事，然后使用iframe.contentWindow.location.href读取终末的iframe确面前地址
隔断办事还有个克己，不错绕过某些ticket的防重放。因为有些单据在受害者端惟有被使用后，可能咱们盗取后也无法愚弄了。使用这种方式偷，不错让单据在受害者端不会被使用。
还有，根据path树立cookie不错精确的让咱们的iframe停在咱们想让它停的url上。
示例代码如下：
#!javascript
var iframe =document.createElement('iframe');
iframe.src="?url=";
document.body.appendChild(iframe);
for (i = 0; i < 20; i++) {
document.cookie = i + ‘=’ + ‘X’.repeat(2000);//不错根据需求树立path
}
iframe.addEventListener('load'， function(){
document.write(iframe.contentWindow.location.href);
for (i = 0; i < 20; i++) {
document.cookie = i + '=' + 'X';
}
}， false);
场景五，跨域从通行证获取登陆ticket
面目为雷同?callback=jsonp，然后通行证会复返个jsonp时势的数据，内部包含认证信息
参考案例 WooYun: 微博上你点我发的结合我就不错登上你的微博（web版和app端均可两个误差一并提交）
偷的几种方式
可能存在jsonp劫捏误差，不错通过jsonp劫捏来偷取用户的登陆左证
Xss误差，去跨域请求此接口得到数据
0x0a 纪念
要而论之，get请求的糟践环球皆没艳羡过，但详尽一些小误差，可能会产生一些出东谈主意象的大误差
树立有筹画其实很苟简，不要使用get方法进行非读操作，不要使用get方法传输敏锐信息，因为你不行能为止你通盘页面不向第三方发起带referrer的资源请求，而且get请求很难保护。它仅仅个灵活烂漫的孩子，你不要让它承载太多株连
在前几天的阿里安全峰会上，我讲了这个议题，终末的不雅众发问时势有东谈主问使用https可不行以治理上头的问题。谜底虽然是不行以，https治理的仅仅客户端到办事端的传输加密防改革。但get请求的数据在两个端，尤其是客户端，https是保护不了的。
至于单点登录问题的树立有筹画色五月第二季，有许多层面皆不错去治理，比如不使用get，不让挫折者发起伪造的单点登录请求等等， 这些细节需要具体问题具体对待，这里就不细讲了。有需求的女网友不错暗里找我疏通，共同为互联网的安全学习最初
|
