Przykład do Holes in most preg_match() filters Stefana Essera:
Praktyczne wykorzystanie tego typu błędu, jeśli nie korzystamy z modyfikatora “m”, jest mało prawdopodobne, ale w pewnych okoliczościach może prowadzić do poważnych konsekwencji. Dla pewności warto wykorzystać modyfikator D (mało znany, bo nieobecny w Perlu) lub \A i \z zamiast ^ i $.
…..hmmm, a czy jeżeli w adresie umieścimy dwa adresy e-mail (oddzielone \n) to czy funkcja mail() wyśle dwa maile?
Kolejne linie to kolejne nagłówki emaila, podobnie jak w przypadku dodatkowych nagłówków wstawianych w czwartym parametrze tej funkcji. Wstrzykując znak \n w przypadku funkcji mail() możemy doprowadzić do usunięcia następnych nagłówków lub wstawienia własnych (BCC, Content-Type, From, itp.).
Akurat w funkcji mail() nie stwarza to zwykle niebezpieczeństwa (chociaż może pozwalać np. na wykorzystanie naszej aplikacji do rozprowadzania spamu), ale przy pomocy preg_match weryfikowane są najróżniejsze typy danych.
W wydanej wczoraj wersji PHP 5.2.2 zablokowana została możliwość wysyłania dodatkowych nagłówków w pierwszych dwóch parametrach funkcji mail(), ale czwarty parametr jest zawsze podatny na takie ataki, jeśli dane od użytkownika nie są odpowiednio filtrowane.
http://www.securephpwiki.com/index.php/Email_Injection
Dokładnie, ten artykuł świetnie opisuje problem wstrzykiwania nagłówków mailowych, chociaż przyznam, że proponowane rozwiązania nie do końca mi się podobają. eregi() nie jest bezpieczna dla danych binarnych, a rozwiązywanie każdego problemu zewnętrznym (3rd party) patchem może szybko doprowadzić do sytuacji, w której nie jesteśmy w stanie aktualizować PHP do nowszej wersji. Proponowałbym preg_match() (whitelist) lub ewentualnie $header=str_replace(array(”\r”,”\n”),array(”",”"),$header) (blacklist).
Na marginesie: przykładowy formularz jest podatny na XSS (PHP_SELF).