4 ms·
What's scary here is that PHP returns 0 (meaning no match found) rather than FALSE, which is the error return value of preg_match. It's this attitude of failing
by paulgb 16y ago
What's scary here is that PHP returns 0 (meaning no match found) rather than FALSE, which is the error return value of preg_match. It's this attitude of failing silently that makes PHP feel like a dangerous language.
Granted, it's smart that PHP does have a default backtrack limit. I believe this would have prevented errors like the django forms DoS vulnerability from a while back.
- bigmac 16y agoPerl has taken care to address some of these issues. See 'Algorithmic Complexity Attacks' in perldoc perlsec. For example, the keys of a hash table are guaranteed to be returned in random order, to prevent hash collision attacks on the hashing algorithm itself. It appears they punt on the particular issue of regex's running out of memory though. Developers are told "careful crafting of the regular expressions can help," and told to read "Mastering Regular Expressions." As I recall, Boost's regex library will throw an exception if evaluation of the regex is getting out of hand. It's funny, I generally judge a regex library on how compatible it is with perl's implementation. In this case though, I might actually prefer the behavior of Boost and PCRE.
- ars 16y agoLine 64 of http://svn.php.net/repository/php/php-src/trunk/ext/pcre/php_pcre.c http://svn.php.net/repository/php/php-src/trunk/ext/pcre/php... shows that they do handle it. And you use the preg_last_error() function to see it. The return false is for php errors (i.e. programming errors, which also raise warnings), not library errors.
- paulgb 16y agoSetting a flag and failing silently is still failing silently.