>通过HTTPS接受来自用户的表单POST(实际的HTML表单位于不同的站点上)
>将表单帖子重写为JSON
>通过单独的HTTPS连接将其发送到内部服务器,并进行多服务器故障转移
>等待JSON中的回复,包含成功或错误原因
>将“303”重定向从一个返回到成功URI或失败URI,将错误原因作为查询参数
此服务器通常承受的负载很小,但由于没有访问限制,服务器显然可能受到DOS等的攻击.
然而,这里的真正问题是安全性对于服务器来说绝对是至关重要的 – 服务器涉及具有足够大量的支付交易以使其成为理想的破解目标.服务器位于IPS之后,但是直接连接到互联网,并且将直接终止来自最终用户浏览器的HTTPS连接,而无需任何干预反向代理或SSL加速器等.
所以,我的问题是,哪个Java Web服务器是最安全的选择呢？
或者,如果你真的认为这些请求不应该由Java直接接收,而是由lighttpd或其他东西接收,你可以提出其他建议.但只有它能满足上面给出的要求.
一个非常好的答案将触及这些问题：
> OpenSSL与Java加密与替代方案的相关安全性(所有漏洞都存在)
> Java VM功能的相关安全性(例如最近的XML解析漏洞)
> Web服务器的HTTP头解析的相关安全性(几乎所有似乎都有漏洞)
>可选压缩的相关安全性(zlib存在漏洞,mod_deflate除此之外还有单独的漏洞)
解决方法
我建议使用Tomcat并遵循Improving Apache Tomcat Security中的步骤.Tomcat具有通用和开源的优点,因此它得到了很多关注和快速修复.许多攻击都是针对你甚至不需要的东西,所以禁用你能做的一切.将web.xml配置为仅接受您期望的URL路径,并为其他所有路径提供错误.
听起来您不需要在Web容器前面使用Apache HTTPD.最好是减少攻击向量的数量,并将Web请求直接发送到Web容器.无法知道哪些HTTPD或Java会为SSL和gzip发现更多漏洞.然而,如果您只使用Java,那么您至少不会对HTTPD的其余部分开放,而不是Java的一组有限的本机实现问题.
确保Java和您的Web容器保持最新.如果没有,网络和操作系统强化也应该进行研究.您可能还希望查看每日扫描Web漏洞以了解新威胁.
