Java中面向internet的web服务器的安全选择是什么？

我需要实现一个可以从internet公开访问的服务器。服务器有一个非常简单的任务：

• 通过HTTPS接受用户的表单帖子（实际的HTML表单位于不同的站点）
• 将表单post重写为JSON
• 通过单独的HTTPS连接将其发送到内部服务器，并进行多服务器故障转移
• 等待JSON中包含成功或错误原因的回复
• 返回从成功URI或失败URI的“303”重定向，将错误原因作为查询参数

此服务器通常承受的负载很小，但由于没有访问限制，服务器显然会受到DOS等攻击

然而，这里真正的问题是，安全性对服务器来说绝对是至关重要的——服务器参与的支付交易量大到足以使其成为理想的破解目标。服务器位于IPS后面，但直接连接到internet，并将直接终止来自最终用户浏览器的HTTPS连接，而无需任何干预反向代理或SSL加速器等

所以，我的问题是，对于这样的目的，哪个JavaWeb服务器是最安全的选择

或者，如果您确实认为此类请求不应该由Java直接接收，而应该由lighttpd或其他方式接收，那么您可以提出其他方式。但前提是它能够满足上述要求

---

一个非常好的答案会涉及到这些问题：

• OpenSSL、Java加密和备选方案的相关安全性（都有漏洞）
• Java VM功能的相关安全性（如最近的XML解析漏洞）
• web服务器HTTP头解析的相关安全性（几乎所有解析都存在漏洞）
• 可选压缩的相关安全性（zlib有漏洞，mod_deflate有单独的漏洞）

---

大多数服务器都能做到这一点。Tomcat是一个明显的选择。Apache背后的Tomcat也很常见。如果使用JavaEE，任何应用程序服务器都可以工作。

我认为，您的主要关注点应该是遵循最佳安全实践，并使您的软件保持最新，而不是具体选择哪个软件。预测未来的脆弱性几乎是不可能的。而且，具有大量过去漏洞的软件并不一定意味着它的安全性较低，它可能更经常地成为攻击目标，因此也更经常地被修复。在这方面，您需要定期更新的软件，并且您有一种简单的方法来定期获取这些更新

我建议使用Tomcat并按照中的步骤进行操作。Tomcat具有通用性和开源性的优点，因此它得到了很多关注和快速修复。很多攻击都是针对你甚至不需要的东西的，所以请禁用所有你能禁用的东西。将web.xml配置为仅接受预期的URL路径，并为其他所有内容提供错误

听起来您不需要在web容器前面使用ApacheHTTPD。最好是减少攻击向量的数量，让web请求直接进入web容器。不可能知道哪个HTTPD或Java会发现更多SSL和gzip漏洞。然而，如果您只使用Java，那么您至少对HTTPD的其余部分不开放，而Java的本机实现关注点有限

---

确保Java和web容器保持最新。网络和操作系统强化也应该研究，如果它们还没有被研究的话。您可能还想查看web漏洞的日常扫描，以了解新的威胁。

如果您需要简单而单一的用途，我将尝试使用Grizzly——代码更少，bug更少。它有一些SSLConfig类来设置HTTPS，尽管我没有使用它

虽然共同基金经理很快就指出，过去的表现并不是未来表现的指标，但您可以查看列表中所考虑工具的安全历史记录。当然，它只列出了公众已知的bug，而一个没有人知道的小项目（因此没有太多公众已知的bug）可能只是一堆正在运行的代码。但我发现CVE是一个非常有用的工具谢谢，我知道CVE和我能在那里找到的信息。我正在寻找比我半天的谷歌所能找到的更深奥的答案。我很清楚，几乎所有的答案都是“有能力的”。然而，我正在寻找一个有最好的安全记录。Apache显然非常常见，但它也有长期的安全漏洞记录，需要频繁更新以保持安全。Tomcat还有很多由恶意HTTP头触发的漏洞。但我并不是说，与其他选择相比，它们仍然不是最好的选择……所有其他安全方面都在处理中。除此之外，该服务还获得了QSA的PCI认证。谢谢你的回答。然而，“Tomcat处理SSL和gzip更安全，因为Java”有些误导，因为SSL和gzip都是用Java中的C实现实现的，而不是纯Java。导致远程代码执行的zlib漏洞对于Java和其他实现一样有效。使用PureTLS和JZlib实际上可以实现Java安全承诺。由于需求非常有限，我不需要Tomcat的大部分功能，必须确保它们被禁用。其中as-Jetty采用了更模块化的方法，允许完全排除不需要的代码。你认为这是重要的一点吗？这会打破Jetty和Tomcat之间的平衡吗？对于Tomcat和Jetty来说，这是一个很好的观点。不过，在Tomcat中禁用某些东西并不太难，而且还有一些东西需要改进