![]() |
![]() |
|
March 07, 2006Input Validation Bug in ASP.NETSo I found an interesting condition today in ASP.NET while doing some code in VS.NET 2003. If you use a RegularExpressionValidator on a web form it will NOT be called if the field is left blank. In other words, even though you apply regular expression input validation on a control, it won't actually be executed if the field is blank. To me, this is a bug. If I add a regex of "^\d{1,2}$" (which means the field must have a MINIMUM of 1 digit and a MAXIMUM of 2 digits), it should be honored. In ASP.NET, that is apparently not the case. The fix is to add a second validator BEFORE it, using the RequiredFieldValidator. The fix looks something like:
So if you are trying to be a good net-izen and are trying to validate your input with regular expressions, you need to test this edge case. There is a good chance you may not actually be catching this. I contacted a dev security evangelist at Microsoft about this, and he confirms that this condition exists. He also tested it against VS.NET 2005, and apparently the same behaviour exists there as well. But Microsoft doesn't consider this a bug. Apparently the RegularExpressionValidator is not supposed to be tested against a null like its sister System.Text.RegularExpression. And that kind of makes sense since in a postback if there is no data it simply won't exist in the query string. After further discussion, it was brought up that if it didn't work this way, optional fields couldn't otherwise use a RegularExpressionValidator if it worked as I would expect it. I think this needs to be documented better. If someone new to validating controls ASSUMES regex is honored in testing against a blank string, they will be sadly mistaken. You MUST validate against a NULL first with a RequiredFieldValidator. Interesting find. Hope that's useful to someone out there. Posted by SilverStr at March 7, 2006 09:51 AM | TrackBackComments
Yep! I am the one that Dana spoke with and I am glad he did as I was not aware of this until I researched into the behavior. I agree that developers need to be aware of this behavior. Hey looks like Dana was doing some solid security testing to reveal this and not take it for granted!!!! Posted by: dan sellers at March 7, 2006 10:34 AMI don't think it's a bug as such. And I think it's quite a useful behaviour. Say you want to allow a field to be optional but fail if there is a value supplied the doesn't match a condition such as range or formatting e.g. allowing a UK postcode to be optional but if one is supplied then it must be a valid UK postcode. The range validator behaves like this too I seem to remember. No validation fires unless a value is supplied. Kev Have too agree with Kev - if you have a regular expression validator and you dont enter a value (an expression to validate after all) then you should either allow this, or have a required field validator as well. Posted by: gregor suttie at March 7, 2006 12:21 PMYes, devs should be aware of this behavior. But, it is documented pretty well. From the VS.NET 2003 help in the remarks for the RegularExpressionValidator control: Note If the input control is empty, no validation functions are called and validation succeeds. Use a RequiredFieldValidator control to prevent the user from skipping an input control. The exact opposite is true in Ruby on Rails (if you'll pardon the comparison). A field *must* match its regular expression validator or it is an error. I was used to ASP.NET's behavior, so I slammed my hands on my desk and screamed "How do I make a field optional?!" Easy: just wrap the regular expession in ()? (i.e., match zero or more occurences of). Personally, I like Ruby on Rails implementation better. You only have *one* validator for each field, as opposed to two in ASP.NET. Posted by: Aaron Jensen at March 14, 2006 11:32 AMPost a comment
|
![]() ![]()
My 5 Favorite Books
Writing Secure Code
Secure Programming Cookbook Security Engineering Secure Coding Principles & Practice Inside the Security Mind ![]()
My 5 Favorite Papers
Smashing the Stack
Penetration Studies Covert Channel Analysis of Trusted Systems DoD Trusted Computer System Evaluation Criteria NSA Security Recommendation Guides ![]()
Archives
March 2006
February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002 August 2002 July 2002 ![]() |
|