See my answer to comment #2

From the first 2 comments I see that I have choosen a bad example. I wanted a very simple regular expression just as demonstration.

Of course for plain numbers a cast to int and similiar things are good. I did not take an email address as example, because there are millions of email regular expressions.

And one of those email regular expression that misses the D modifier is the validate email filter in PHP's ext/filter.

Honestly I pretty much doubt that removing \n would be a good idea.

I am not a friend of modifying content the user sent to me. Therefore the comment of guy #6 is something I would never do.

One should never ever try to repair user input. Removing a final \n would be exactly this. The only thing I could do would be removing the whole variable if \n is at the end and that could be fatal if some browser has a bug with multiline edit boxes and formular POSTs over GET.

Thank you for reading the other comments prior writing your own comment and stating the obvious again.

I have no clue what you were trying to achieve, because s9y most probably killed your PHP tags in the comment.

Try again.

"Okay, that was simplistic, but it was to say the regexp was not the cause, it was the misuse of the result."

Sorry but you are completely missing the point. It was not the misuse of the result that caused the problem, but the fact that the regular expression was not doing what people are told.

Again I can only guess what your code looked like but saying "i always consider using user submited data as a bad practice" is nonsense. For example when it comes to storing user submitted data in the database. I have seen a lot of nonsense filters that stripped everything beside a known good whitelist from the input.

This is the wrong approach when it comes to arbitrary user supplied data. When the user tells you that his favourite word is {${phpinfo()}}'/* then it most probably is his favourite word and your job is to put this data into the database and not to enforce your own idea what words you allow him to like.

Filters and validators can only be used where filtering and validation makes sense.

Documentation of the D modifier is here:

http://www.php.net/manual/en/reference.pcre.pattern.modifiers.php

Seth,

you are missing the point that the world does not only consist of a single variable. And that email addresses are not only given to the mail() function.

A single newline at the end can be a problem for all the stuff that follows.

Not long ago some guy wanted "us" (those who read his blog) to add debugging information into SQL queries so that you can see who caused the problem.
Now imagine the SQL Query looks like

// $firstname $lastname
SELECT * FROM ...

Now guess what happens if $firstname ends in a \n. Suddendly $lastname ends up in the next line and might allow SQL injection.

And this is not the only example.

Imagine a session ID sent by the browser ends in a \n and this results in PHP code like header("Set-Cookie: sessid=$sessid\nNext-Header: $userinput");

While header() was never intended to be used with multiple HTTP headers, people used it like that. In the previous example $sessid might end on \n which results in the end of the HTTP Headers before Next-Header: and suddenly $userinput is in the body and might contain JavaScript...

There are many more examples where this can be dangerous. f.e. many Shells consider \n the separator between two commands...

There are holes in most preg_match() filters.

Noone says that they all lead to exploitable problems, but there are holes. So there is no FUD at all, boy.

Anonymous you misunderstood the complete blog posting.

You cannot inject newlines whereever you want. It is only possible to inject A SINGLE newline at the end.

First of all you should not assume that just because YOU trim user input everyone does this.

Secondly the world does not consist of a single data entity. Where one email address/data entitiy is embedded into headers/shell commands/... there is usually another or even more.

A newline at the end of one data entity might not look dangerous to you becaue you think in the size of single elements. However when I have a newline in the middle of a shell command for example this is considered the end of the command and start of a new one. (atleast in many unix shells)

So something like

system("do_a $userinput1 $userinput2");

suddenly becomes dangerous if $userinput1 has a newline at its end.
(PS: don't tell me that you should escape the arguments, because that is not the point. If userinput1 already passed a preg_match("/^[0-9]*$/,....);
people assume it is save to put it into the shell command.)

With email injection it is the same. It always depends on the context. A single additional newline at the end of an email header will f.e. terminate the headers (because now there are 2 of them). Suddenly everything afterwards is considered part of the email body. So suddenly the attacker is able to manipulate the email body. This is also an email injection attack...

Use you imagination... In many contexts a single newline at the end can cause problems.