Fierozen / owasp-esapi-java

Automatically exported from code.google.com/p/owasp-esapi-java
Other
0 stars 0 forks source link

isValidDate fails to identify injection attack #251

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Instantiate a SimpleDateFormat object called myFormat
2. Make a call to ESAPI.validator().dateIsValid using the following arguments: 
"datetest4", "September 11, 2001' union select * from another_table where 
user_id like '%", myFormat, false

What is the expected output? What do you see instead?

I think it's reasonable to expect the library to report "September 11, 2001' 
union select * from another_table where user_id like '%" as an invalid date; 
but, the method returns true.

What version of the product are you using? On what operating system?

I fetched the source from http://owasp-esapi-java.googlecode.com/svn/trunk, 
revision 1867, compiled using the Oracle JDK 6 Standard Edition (build 
1.6.0_24-b07) in Eclipse configured for J2SE-1.5 compliance. The host OS was 
Windows 7.

Does this issue affect only a specified browser or set of browsers?

No.

Please provide any additional information below.

I added the following line to org.owasp.esapi.reference.ValidatorTest.java at 
line 330:

assertFalse(instance.isValidDate("datetest4", "September 11, 2001' union select 
* from another_table where user_id like '%", format, false));

and this assertion fails.

I believe I have traced the root cause to 
org.owasp.esapi.reference.validation.DateValidationRule.java line 97:

return format.parse(canonical);

According to the JavaDoc for DateFormat.parse at 
http://download.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html#par
se%28java.lang.String,%20java.text.ParsePosition%29, the parse method does not 
necessarily use up all characters to the end of the string. Thus the current 
implementation apparently reads to the end of the valid date and returns true, 
without checking whether additional characters are present.

Original issue reported on code.google.com by andrew.g...@gmail.com on 7 Nov 2011 at 1:28

GoogleCodeExporter commented 9 years ago
This is being looked at currently

Original comment by chrisisbeef on 18 Sep 2014 at 8:47