阻止对CDN上的内部资源的请求
在这种情况下，防火墙的存在有一个原因:阻止外部请求访问内部资源。
假设我有两个HTTP服务器在运行:一个在端口8080上，另一个在端口8081上。
8080端口上的服务器是一个可公开访问的基于Node的网站(在本例中由express提供支持)，并对每个请求运行以下代码，这基本上是一种简单的CDN，从用户定义的URL (在X-Cool-URL头部中)请求数据，并将请求的正文返回给我的网站域名下的用户。request是request模块，req是express请求对象，res是express响应对象。(显然，这段代码并不实用，也不能保证错误，但它是一个很好的例子。)
const url = req.get("X-Cool-URL"); // some example user input value
request(url, (error, response, body) => { // request said arbitrary resource
res.send(body); // send response back to user
});端口8081上的服务器是一个HTTP服务器，它通过内部请求执行操作；通过端口8081的外部网络被防火墙阻止，这是有充分理由的。任何用户定义的数据都不应该发送给它。假设我不是这个web服务器的程序员，并且对它的代码没有任何控制或访问权限。这个服务器对任何给定的请求输入到底做了什么都是无关紧要的。重要的是，允许向其发送任意数据将是一个安全风险。
...but我可以从任何外部命令行运行此命令。
curl -H "X-Cool-URL: http://localhost:8081/something/malicious" http://example.com:8080这带来了一个问题:用户可以使用我的公共web服务器通过内部网络下的localhost:8081请求私有web服务器。我仍然希望人们能够通过我的web服务器在端口8080上请求其他公共域，并且我仍然希望能够作为开发人员在内部请求8081，但我不希望其他任何人能够利用我的服务器任意访问8081，而不是防火墙。我如何才能使用户不可能使用我的公共web服务器来请求任何内部资源？
我想要保护的端口可能并不总是明确和已知的，所以简单地通过我的web服务器拦截8081是不现实的。只阻塞对localhost的所有请求也是不现实的，因为还有其他方法可以请求内部资源(例如使用127.0.0.1)。甚至可以设置指向本地资源的DNS记录，因此只将一组URL列入黑名单也不起作用。白名单也不是一种选择，因为它会破坏CDN的观点，使客户端能够请求任何外部资源。我感兴趣的是一种在任何情况下都能检测URL是否为内部URL的方法。
回答 1
Stack Overflow用户
发布于 2018-03-24 06:17:16
案例1:您在端口8080上控制代理服务器
因此，如果您控制代理服务器，而不是它背后的web服务器，那么实际上很容易防止这样的事情:您只需要从请求中过滤某些HTTP标头，而不处理这些请求。
最安全的做法是使用您允许在X-Cool-URL报头中使用的主机名的白名单。然后只需检查URL是否与白名单匹配。或者，您可以使用黑名单进行过滤，但这会有点麻烦，因为您不仅要考虑localhost，还要考虑不同的IP范围。您不希望X-Cool-URL指向127.0.0.1、192.168.x.x等任何内容。
案例2:您在端口8081上控制后端服务器
如果您无法控制代理服务器过滤哪些请求以及它转发给您的HTTP请求，则必须检查请求来自何处。您可以使用如下代码获取有关原始请求者的详细信息：
var ip = req.headers['x-forwarded-for'] || req.connection.remoteAddress;如果ip地址不在您允许的范围内，请不要应答请求。这样，您可以从防火墙后运行的其他服务器授予访问权限，同时阻止来自代理的访问。
开发人员访问
一旦你实现了这两种机制中的任何一种，你仍然希望允许对后端的开发访问。最简单的方法是使用一个只有你知道并且不容易被猜中的密钥。然后将这个密钥作为附加的HTTP request header (X-Cool-Secret)提供，或者作为X-Cool-URL本身的一部分作为查询参数提供。
更多的思考
像这样的场景本质上是不安全的。一旦你提供了通过公共互联网访问你的后端，你就需要为攻击做好准备。即使你的代理可以过滤很多东西，但还是有可能有人找到了方法。在同一物理机(或VM)上同时运行代理和后端会增加额外的安全风险。一般的经验法则:不要这样做。
允许从开发机器访问也是有风险的。密钥可能会泄露，密码可能会被窃取，IP地址可能会被欺骗。没有简单的方法来防止复杂的攻击。这种公共访问有许多您通常应该避免的权衡。请尝试使用SSH作为进入隔离区(防火墙和代理之后的所有内容)的安全通道。这提供了一个更安全的环境，您可以在Node/Express中自行构建。
尽管如此，希望这能有所帮助。
https://stackoverflow.com/questions/49458610
复制相似问题