> Jim, unless I misunderstand something, none of the issues described in the paper are "vulnerabilities" in the languages
I think the rounding errors could lead to vulnerabilities in some financial applications. Since this flaw is still present in the latest versions of Java 5, at least, it might be worth bringing this to Sun's attention again. I'd also be curious if this flaw exists in non-Sun JVM's.
As a side note, we do the Infinite and NaN checking in the ESAPI default implementation for double verification, at least.Good to know, thanks! I'll probably take the opportunity, when I have a bit more time, to analyze this a bit and look for any issues as well.
For your consideration:
/**
* Returns a validated number as a double. Invalid input
* will generate a descriptive ValidationException, and input that is clearly an attack
* will generate a descriptive IntrusionException.
*/
public Double getValidDouble(String context, String input, double minValue, double maxValue, boolean allowNull) throws ValidationException, IntrusionException {
if (minValue > maxValue) {
//should this be a RunTime?
throw new ValidationException( context + ": Invalid double input: context", "Validation parameter error for double: maxValue ( " + maxValue + ") must be greater than minValue ( " + minValue + ") for " + context );
}
if (isEmpty(input)) {
if (allowNull) return null;
throw new ValidationException( context + ": Input required: context", "Input required: context=" + context + ", input=" + input );
}
try {
Double d = new Double(Double.parseDouble(input));
if (d.isInfinite()) throw new ValidationException( "Invalid double input: context=" + context, "Invalid double input is infinite: context=" + context + ", input=" + input );
if (d.isNaN()) throw new ValidationException( "Invalid double input: context=" + context, "Invalid double input is infinite: context=" + context + ", input=" + input );
if (d.doubleValue() < minValue) throw new ValidationException( "Invalid double input must be between " + minValue + " and " + maxValue + ": context=" + context, "Invalid double input must be between " + minValue + " and " + maxValue + ": context=" + context + ", input=" + input );
if (d.doubleValue() > maxValue) throw new ValidationException( "Invalid double input must be between " + minValue + " and " + maxValue + ": context=" + context, "Invalid double input must be between " + minValue + " and " + maxValue + ": context=" + context + ", input=" + input );
return d;
} catch (NumberFormatException e) {
throw new ValidationException( context + ": Invalid double input", "Invalid double input format: context=" + context + ", input=" + input, e);
}
}
This is nice work. At the beginning, reading about the problems with using floating point or double values for financial values, I was thinking "yeah, yeah programming 101", and personally I think that the bit about many small transactions which round favorably (i.e. the currency exchange type problem) is also fairly well known. However, I think there is much less awareness of thing such as using "NaN" or "Infinity" in inputs to bypass filters. I know I'll be playing around with the related attacks for a bit to get a feel for them.
Jim Manico wrote:This is a very interesting article, nice work.
I would recommend you add *exact* versions of the various API's being used.
At the very least, all of your Java samples do indeed check out against Java 1.5_0_16 on Windows.
Have you reported these issues to Sun/Microsoft?
Jim, unless I misunderstand something, none of the issues described in the paper are "vulnerabilities" in the languages (which are the only Sun/Microsoft products mentioned I believe). Instead, behavior of the language which may not be immediately obvious to all programmers writing web applications is discussed. In other words, if you fail to account for the language behavior when interpreting "NaN" as a valid number your application may be vulnerable, but that is not to say that Java is. As such, reporting/embargoes/etc seems not to apply.
-Nathanael
- JimBreaking the Bank (Vulnerabilities in Numeric Processing within Financial Applications)
By Adam Boulton, Stephen De Vries, Kevin O'Reilly, July 15, 2008
---------------------------------------------------------------------------- Join us on IRC: irc.freenode.net #webappsec
Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA