防止来自 gorilla/mux 的打开 URL 重定向

golang学习网今天将给大家带来《防止来自 gorilla/mux 的打开 URL 重定向》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习Golang或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

我正在使用 go + gorilla/mux v1.4 框架开发 restful web 应用程序。发布后的一些基本安全测试揭示了应用程序中的开放 url 重定向漏洞，该漏洞允许用户使用外部 url 提交特制请求，导致服务器以 301 重定向进行响应。

我使用 burp suite 对此进行了测试，发现任何重定向到应用程序中的外部 url 的请求似乎都会以 301 moved permanently 进行响应。我一直在研究在发送 301 之前拦截这些请求的所有可能方法，但这种行为似乎已融入 net/http 服务器实现中。

这是发送到服务器的原始请求 (myapp.mycompany.com:8000)：

get http://evilwebsite.com http/1.1
accept: */*
cache-control: no-cache
host: myapp.mycompany.com:8000
content-length: 0

任何时候的响应都是：

HTTP/1.1 301 Moved Permanently
Location: http://evilwebsite.com/
Date: Fri, 13 Mar 2020 08:55:24 GMT
Content-Length: 0

尽管对 request.url 进行了检查以防止在 http.handler 中发生这种类型的重定向，但我还是没有运气让请求到达处理程序。看起来基础 http web 服务器正在执行重定向，但不允许它到达 pathprefix("/").handler 代码中定义的自定义处理程序代码。

我的目标是确保应用程序针对此类请求返回 404-not found 或 400-bad 请求。有其他人用 gorilla/mux 遇到过这种情况吗？我在 jetty web 应用程序上尝试了同样的操作，发现它返回了一个完全有效的 404。我已经在这方面研究了几天，确实可以使用一些想法。

解决方案

这不是声称的开放 URL 重定向安全问题。此请求无效，因为路径包含的绝对 URL 的域与 Host 标头不同。没有理智的客户端（即浏览器）可以被诱骗首先发出这样的无效请求，因此不存在实际的攻击向量。

当然，可以创建自定义客户端来提交此类请求。但是，自定义客户端也可以以非标准方式解释服务器响应，或者直接访问恶意 URL，甚至无需联系您的服务器。这意味着在这种情况下，客户端本身就是问题所在，而不是服务器响应。

本篇关于《防止来自 gorilla/mux 的打开 URL 重定向》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！