一次sso攻防研究
使用中间人模拟单点登录过程，拦截用户cookie中sessionid，同时确保其可用
*secretRequest除了sessionid、serviceid，可能还有个时间，比如两个时间对比需在10秒以内，像cas的st只能用一次，且需要在10s以内
这些是猜测，是作者根据自身经验设计，要达到跑通（非绝对安全）效果，最少需要这些字段，加入更多字段则更安全
*解密secretResponse那一步，转到/resource/{id}同时有一个植入csrftoken的过程，非必须，只要有信任的sessionid，在之后的单独请求也可另外申请
1
篡改第三个链接sso的返回报文中的重定向链接到proxy，2个问题
1.1 由于需要带上sso的cookie，所以必须由浏览器发起这个请求，而且不能是ajax请求，也不能由服务器发起，而浏览器的非ajax返回报文是无法篡改的；
1.2 又由于重定向的链接在加密字符串中，即使是对称加密，也无法篡改
2
先由proxy到resource发起一个服务端请求，申请并拦截一个cookie（同时会有一个secreteRequest，弃之），以此代替第一二个链接，然后由proxy所在域名带着这个cookie生成一个secretRequest，需要一个被sso服务信任的加密算法生成，看上去sso服务好像不会验证referer，然后发起sso浏览器非ajax请求，由sso返回报文重定向回proxy（间接篡改1中所述重定向）取得secretResponse，拿着先前的cookie和这个secreteResponse去resource发起服务端请求，如果resource解密后没有对比域名、secreteRequest，仅获取ssoid并与该cookie绑定，则成功
3
由proxy到resource发起一个服务端请求，截获cookie，并让浏览器正常执行返回body中的html代码，在第四个链接中resource将激活这个cookie
3.1 这个cookie的取得是由服务端请求的，故未经浏览器植入，在第四个链接激活时，如果resource解密secreteResponse，对比cookie而不单单时取得secreteResponse中的cookie、ssoid并完成内存绑定，则不能成功
3.2 可能缺一个csrf token，这个东西在第四个链接response才会植入，这种情况proxy失去控制权拿不到，但不一定必须，拿着cookie再申请也可
****************************************************************
服务端请求：可随意篡改报文，但对浏览器域名下的cookie没有读写权限
浏览器ajax：跨域及跨域时的cookie需要服务端支持，如支持，可篡改报文
浏览器非ajax：对cookie完全友好，但无法篡改返回报文，中间人没有切入点，除非在传输层出手而不是应用层
---------------------
所以http协议+浏览器安全机制很牛逼，这个sso也相当严密，三路切入功而不破
sso攻防.zip
