安全工程师只能向拒绝服务漏洞 Parse Double 低头？（安全管理有漏洞）

安全工程师只能向拒绝服务漏洞 Parse Double 低头？（安全管理有漏洞）

据不完全统计，乌云平台自成立以来，已收集到的电商平台漏洞总数达 1169 个，其中 2015 年电商平台漏洞数为 414 个，相比于 2014 年，漏洞总数上涨了68.98%。对于安全工程师们来说，则需要加班加点保障网站的稳定性和安全性。数千亿的消费额，让所有的电商平台工程师，对安全问题不敢有一丝怠慢。

拒绝服务漏洞是在一些遗留系统中仍然存在的老错误，在 Windows 与 Linux 的 JDK1.623 及更早 JDK1.527 及更早 JRE 1.4.2_29 及更早的版本中都存在这一漏洞。对于使用 Apache Tomcat 服务器的系统，若其 JRE 比较脆弱，未经授权的用户完全可以耗尽其所有资源。

实现方式——实现 java.lang.Double.parseDouble() 及其相关方法中的漏洞会导致线程在解析[2^(-1022) - 2^(-1075) : 2^(-1022) - 2^(-1076)]范围内的任一数字时造成线程悬停。这个缺陷可以用来进行 DOS（拒绝服务）攻击。例如：下面的代码使用了较为脆弱的方法。

Double d = Double.parseDouble(request.getParameter("d"));

攻击者可以发送这样的请求，其参数 d 在上面的范围中，例如「 0.0222507385850720119e-00306」 ,进而导致程序在处理该请求时悬停。

黑客新闻中的评论指出，BigDecimal.doubleValue 方法实际上只是将参数转化为字符串，然后调用 Double.parseDouble 方法。因此，非常不幸，上面的机制只有在我放弃一些精度调用 Math.pow(10, exponent) ，而不使用 scaleByPowerOfTen 时会起作用。上面的版本，很遗憾，不起作用。

尽管这个错误已经在 JDK 1.6_24 及之后的版本得到修复，安全行业研究机构发现许多 Java 系统可能还在运行有风险的老版本。普遍的建议是升级系统或者单纯地标准化清理后的字符串，将其传入新的 java.math.BigDecimal() 方法，再将结果转化为基本 double 类型。遗憾的是，BigDecimal 的构造函数也会调用麻烦的 Double.parseDouble 代码，因此我们又回到了原点。最后，我们还可以尝试下面的代码，虽然不能说它高效，但是它通过了所有 Float 测试，不会像 Double.parseDouble 那样拒绝服务。

public static double parseDouble(String value) {String normalString = normalizeDoubleString(value);int offset = normalString.indexOf('E');  BigDecimal base; int exponent; if (offset == -1) { base = new BigDecimal(value); exponent = 0; } else { base = new BigDecimal(normalString.substring(0, offset)); exponent = Integer.parseInt(normalString.charAt(offset + 1) == '+' ? normalString.substring(offset + 2) normalString.substring(offset + 1)); } return base.scaleByPowerOfTen(exponent).doubleValue();}

这种方式虽说有一定效果，算不上聪明和高效。那么是否有更好的方式呢？