URL

IE的URL编码问题

Posted by Cai Qiqi on 2017-06-11

参考:
http://blog.innerht.ml

处理URL很容易搞错。有时候服务端对URL验证有一点点不准确都可能造成一些问题。这次呈现两个跟IE在处理URL重定向方面不当的问题。

GitHub OAuth Code Theft

URL编码,或者叫百分号编码,通常用在query string或者request body中。Hostname同样接收URL编码。然而当IE在重定URL编码过后的hostname的时候,发生了奇怪的事。比如,如果你用Windows 7/8.1的IE浏览器VS 其他浏览器访问以下链接的时候,你会发现目的地址是完全不同的。

https://httpbin.org/redirect-to?url=http://%2577%2577%2577%252E%256D%2569%2563%2572%256F%2573%256F%2566%2574%252E%2563%256F%256D/test

注:httpbin.org可以自己看一下它们主页上的介绍。
通过curl发现结果如下:

➜ ~ curl -i "https://httpbin.org/redirect-to?url=http://%2577%2577%2577%252E%256D%2569%2563%2572%256F%2573%256F%2566%2574%252E%2563%256F%256D/test"
HTTP/1.1 302 FOUND
Connection: keep-alive
Date: Sun, 11 Jun 2017 06:33:32 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 0
Location: http://%77%77%77%2E%6D%69%63%72%6F%73%6F%66%74%2E%63%6F%6D/test

在IE上的重定向地址是:
http://www.microsoft.com9crosoft.com/test
在其他浏览器上的重定向地址是:
http://www.microsoft.com/test

在Firefox上的测试
这里写图片描述
这个奇怪的行为是由Sergey Bobrov发现的,这跟Michał Bentkowski发现的一个bug相似
其实就是IE用URL编码后的值覆盖了已经过URL解码之后的值,然后把它们混在了一起,于是最终的地址指向了非原始地址。这个bug似乎已经在Windows 10的IE11上修复了,然而在Windows 7/8.1上的IE仍然没有修复。

总是就是,如果一个redirect接收了URL编码后的hostname,用户就有可能被重定向到一个未知的网站。
//TODO

GitHub通过递归地normoalizeing在Location头中的值,修复了这个bug

参考