On the PHP Security Log today, Stefan Esser points out some holes in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.

According to Stefan, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.

On the PHP Security Log today, Stefan Esser points out some holes in most of the filters using preg_match that he's seen in examples and the like all around the web. Some of these things could cause issues that could breach the security of your application.

During the last week I was performing some audits and like so often it contained preg_match() filters that were not correct. Most PHP developers use ^ and $ within their regular expressions without actually reading the documentation about what they really achieve.

However the problem is, that the author of such a regular expression did not correctly read the documentation and mistakes the $ character for the definitive end of the subject.

According to Stefan, the actual documentation for the $ character in a regular expression isn't quite used that way. It does mean "the end" of the match but it can also match against a newline as well. His suggestions? Use the /D modifier on the end of the expression to match the real "the end" and not how it might match otherwise.

Anyone noticing some "quirkiness" happening when they use the eZ Mail component in their scripts and bounce the messages off of a Qmail server, might want to check out this helpful hint from Tobias Schlitt on how he solved it.

While working with the eZ Mail component, for sending some emails comfortably, I noticed some issue with my Qmail installation. With some email accounts that received the emails, the headers were broken and had double line break characters, so the complete email was broken. That (weirdly) happened only with some servers (e.g. Gmail), while my own server handeled the emails gracefully.

He discovers that the issue lies on Qmail's side, where the sendmail wrapper for it looks for a "\n" instead of a "\r\n" line PHP sends at the end of a line. Thankfully, it's an easy fix with the eZ Mail component: [php] [/php] Check out this page for more information on this functionality.

Anyone noticing some "quirkiness" happening when they use the eZ Mail component in their scripts and bounce the messages off of a Qmail server, might want to check out this helpful hint from Tobias Schlitt on how he solved it.

While working with the eZ Mail component, for sending some emails comfortably, I noticed some issue with my Qmail installation. With some email accounts that received the emails, the headers were broken and had double line break characters, so the complete email was broken. That (weirdly) happened only with some servers (e.g. Gmail), while my own server handeled the emails gracefully.

He discovers that the issue lies on Qmail's side, where the sendmail wrapper for it looks for a "\n" instead of a "\r\n" line PHP sends at the end of a line. Thankfully, it's an easy fix with the eZ Mail component: [php] [/php] Check out this page for more information on this functionality.