Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.2.13

Bug #10799 newline allowed at the end of some regex rules
Submitted: 2007-04-21 17:16 UTC Modified: 2007-06-03 08:47 UTC
From: berdir Assigned: avb
Status: Closed Package: HTML_QuickForm (version 3.2.7)
PHP Version: 5.2.1 OS:
Roadmaps: 3.2.8    
Subscription  


 [2007-04-21 17:16 UTC] berdir (Sascha Grossenbacher)
Description: ------------ As pointed out by Stefan Esser[1], a "$" at the end of a regex allows one single \n. So $ needs to be replaced with \z or D-modifier added. This is only a problem with php validation, javascript does not allow a \n at the end with $. I am not sure if this is a BC issue, but in my eyes it should be fixed because of 2 reasons: a) inconsistency between php and js validation b) if I configure a for example a numeric rule, I don't want "123\n" to be allowed. So it is an error and im some cases perhaps even a security problem. the php validation could be fixed easily by replacing "$" with "\z" in the regexes but then the js validation does not work anymore. So, in validate function, there should be used "\z" and in getValidationScript function "$", not sure what is the best way to do this. [1] http://blog.php-security.org/archives/76-Holes-in-most-preg_match-filters.html Test script: --------------- require_once 'HTML/QuickForm/Rule/regex.php'; $regex = new HTML_QuickForm_Rule_Regex(); $regex->name = 'numeric'; var_dump($regex->validate("12345")); var_dump($regex->validate("12345\n")); Expected result: ---------------- bool(true) bool(false) Actual result: -------------- bool(true) bool(true)

Comments

 [2007-05-29 14:42 UTC] avb (Alexey Borzov)
I think that the best idea would be to keep regexps as is (so that client-side validation works) and add 'D' modifier when validating server-side.
 [2007-06-03 08:47 UTC] avb (Alexey Borzov)
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.