[PHP?] gevaren van MIME injectie (Cross Site Scripting?)

[Michali]

We hebben hier een probleempje met een persoon die probeert MIME code te injecteren in een mailje verzonden via een contact formulier. Nu dacht ik zelf dat het vrij onschuldig zou zijn, maar er is toch iemand die me er op heeft gewezen dat het best gevaarlijk kan zijn. Hij liet de term "Cross Site Scripting" ook vallen. Nu heb ik hier wat informatie over opgezocht en ik weet nog niet echt goed wat nou de gevaren zijn.

Ik heb nu gewoon een simpel contact formulier. Dit wordt na verzending verwerkt en verzonden via een mailtje. In dat mailtje worden enkele parameters opgenomen zoals het email adres en de naam etc. Nu heb ik gelezen dat het verwerken van die parameters in de headers gevaarlijk kan zijn, omdat er dan MIME geinjecteerd kan worden. Nu heb ik dit al aangepast, zodat die input parameters gefilterd worden. Alleen vraag ik me af of er nog meer gevaren dan dat zijn.

Iets als

PHP:

"From " . $_POST['name'] . " <" . $_POST['email'] . ">";

Is dus al gevaarlijk.

Wat zou er kunnen gebeuren als de parameters niet gefilterd worden?

[Flapp]

* Flapp heeft het mis , laat maar

[ Voor 89% gewijzigd door Flapp op 30-09-2005 17:05 ]

[NMe]

Mensen zouden de From header kunnen afmaken net zoals je bij SQL inject een query kan afmaken met een ;. Vervolgens een nieuwe header maken door een \r\n in te voegen, en dan kun je in principe elke header kiezen die je wil. Daarna nog even zorgen dat de headers niet corrupt raken door nog een CC of BCC header op te nemen en daarin de rest van het name/email veld op te nemen, en de rapen zijn al gaar, lijkt me.

[PrisonerOfPain]

Michali schreef op vrijdag 30 september 2005 @ 17:00:
Wat zou er kunnen gebeuren als de parameters niet gefilterd worden?

Kans is groot dat je 'bak' dan word gebruikt om spam mee te versturen.

[Bosmonster]

Ah is dat het.. Ik kreeg laatst ook een hele berg van dit soort wazige mailtjes met corrupte headers via het contactformulier..

[Flapp]

kan je dan niet gewoon
addslashes() gebruiken ?,
misschien beetje domme vraag

[T-MOB]

Flapietoetoe schreef op vrijdag 30 september 2005 @ 18:40:
kan je dan niet gewoon
addslashes() gebruiken ?,
misschien beetje domme vraag

Nee, mail headers werken niet met quotes of andere speciale karakters. Je kunt beter het email adres valideren met een regex en in het naamveld alleen maar alphanumerieke karakters toestaan.

[TheBorg]

Ik controleer ongeveer zo:

PHP:

return preg_match("/^[A-z0-9]"."[A-z0-9\._-]*"."@"."[A-z0-9][A-z0-9-]*"."(\.[A-z0-9_-]+)*"."\.([A-z]{2,6})$/", $string);

[DirkT]

misschien niet echt aansluitend op het topic, maar waarom heb je in deze regex dns extensies van 2 tot en met 6 ?

naar mijn weten was 4 het langst of heb ik wat extensies gemist?

[Michali]

Dat is niet zo mooi natuurlijk, als ze zo je machine gebruiken om spam mee te versturen. 'Gelukkig' was ik ook vergeten om te strippen op slashes (en magic quotes staan aan), dus werden de headers niet geheel goed in het mailtje verwerkt. Ik ga denk ik toch idd even een regex toepassen op het mail adres.

[crisp]

SantjeS schreef op zaterdag 01 oktober 2005 @ 13:09:
misschien niet echt aansluitend op het topic, maar waarom heb je in deze regex dns extensies van 2 tot en met 6 ?

naar mijn weten was 4 het langst of heb ik wat extensies gemist?

.museum bijvoorbeeld

[TheBorg]

Inderdaad, en natuurlijk 2 puntjes voor bijv. [e-mail]

[stekkel]

T-MOB schreef op vrijdag 30 september 2005 @ 18:46:
[...]

Nee, mail headers werken niet met quotes of andere speciale karakters. Je kunt beter het email adres valideren met een regex en in het naamveld alleen maar alphanumerieke karakters toestaan.

Een mailheader is opgebouwd als:
key: value\r\n

Dus als je de dubbele punt en \r en \n eruit filterd ben je al een heel eind. Je kan dan in ieder geval geen nieuwe headers toevoegen d.m.v. injection.

Verder moet je er voor zorgen dat er geen 8bits waarden in de rfc822 header opgenomen wordt. Een rfc822 header mag alleen 7 bit waarden bevatten en alles wat anders is moet van een charset encoding worden voorzien.

en nog iets, het betreft hier geen MIME injection maar rfc822 header injection.

[OkkE]

Ik had hier ook last van, ik heb het opgelost door in de Header helemaal niets uit het formulier te verwerken. Mijn contact-formulier wordt dan ook verstuurd met gewoon [e-mail] en niet met het adres dat de bezoeker invult.

Nadeel is natuurlijk dat je nooit gelijk "reply" kunt doen op emails die via het formulier verstuurd zijn, maragoed, voor mijn eigen website maakt dat niet zo uit vind ik. En op mijn werk gebruiken we altijd een regEx-check om te zien of het email-adres wel geldig is, en zo niet: error-melding.

--- edit ---

@frickY:
Daar is dus inderdaad een regEx voor nodig, om uit te zoeken of het wel of niet een correct email-adres is. Of, het zou zelfs al heel simpel kunnen, door zowel het email-adres en de naam te controleren op

code:

/r/n

Als dat in de naam of email-adres voor komt, dan kun je er al wel van uit gaan dat er iets niet klopt.

[ Voor 27% gewijzigd door OkkE op 03-10-2005 10:24 ]

[frickY]

Dat werkt misschien voor mailtje's die je aan jezelf stuurt. Maar mailtjes naar de bezoeker zelf dan?

Ik ga binnenkort eens wat contactformuliertjes testen op deze MIME-inectie Had er nooit zo bij stilgestaan dat je zo allerhande troep in een e-mailtje kan proppen, van BCC's tot attachments...

[Arnout]

Is dit ook veilig?

PHP:

    if((strlen($email)!=0) && (!ereg("^[_a-zA-Z0-9-]+(\.[_a-zA-Z0-9-]+)*@([a-zA-Z0-9-]+\.)+([a-zA-Z]{2,4})$", $email))){
        $error_msg[] .= "E-mail adres is ongeldig, vul dit correct in.<br>";
    }

[NMe]

Veilig? Mjah, lijkt me wel. Er staan wel wat schoonheidsfoutjes in.

PHP:

(strlen($email)!=0)

is gelijk aan:

PHP:

!empty($email)

Verder: [e-mail] gaat niet werken met jouw regexp _{(sorry, toch wel )}, evenals [e-mail].

[Michali]

Hier staat best wel een interessant stukje.

Best wel triest wat iemand op de main page heeft gedaan

@Arnout: ziet er wel veilig uit ja. Als je gewoon de tips in dit topic op volgt en even die pagina doorneemt, dan ben je wel genoeg op de hoogt om injectie te kunnen voorkomen lijkt me.

[ Voor 21% gewijzigd door Michali op 04-10-2005 12:48 ]

[frickY]

Die eregi keurt sowieso een lege string af, due die strlen check is overbodig. Wel kun je checken of hij uberhaupt bestaat (isset()) of een notice te voorkomen.
Ook gok ik dat $email eigenlijk $_POST['email'] zou moeten zijn

[muba]

Jullie weten dat een regexp om ondersteuning te bieden aan bijna alle geldige e-mail adressen er als volgt uit ziet?

code:

[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\
xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xf
f\n\015()]*)*\)[\040\t]*)*(?:(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\x
ff]+(?![^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n\015
"]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\
xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80
-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*
)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\
\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\
x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x8
0-\xff]+(?![^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff])|"[^\\\x80-\xff\n
\015"]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[\040\t]*(?:\([^\\\x
80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^
\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040
\t]*)*)*@[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([
^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\
\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\
x80-\xff]+(?![^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-
\xff\n\015\\[\]]|\\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()
]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\
x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\04
0\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\
n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\
015()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?!
[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\
]]|\\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\
x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\01
5()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*|(?:[^(\040)<>@,;:".
\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]
)|"[^\\\x80-\xff\n\015"]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[^
()<>@,;:".\\\\[\]\x80-\xff\000-\010\012-\037]*(?:(?:\([^\\\x80-\xff\n\0
15()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][
^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)|"[^\\\x80-\xff\
n\015"]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015"]*)*")[^()<>@,;:".\\\\[\]\
x80-\xff\000-\010\012-\037]*)*<[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?
:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-
\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:@[\040\t]*
(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015
()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()
]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\0
40)<>@,;:".\\\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|\\
[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\
xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*
)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80
-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x
80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t
]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\
\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|\\\[^\x80-\xff])
*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x
80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80
-\xff\n\015()]*)*\)[\040\t]*)*)*(?:,[\040\t]*(?:\([^\\\x80-\xff\n\015(
)]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\
\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*@[\040\t
]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\0
15()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015
()]*)*\)[\040\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(
\040)<>@,;:".\\\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|
\\\[^\x80-\xff])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80
-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()
]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x
80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^
\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040
\t]*)*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".
\\\\[\]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|\\\[^\x80-\xff
])*\])[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\
\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x
80-\xff\n\015()]*)*\)[\040\t]*)*)*)*:[\040\t]*(?:\([^\\\x80-\xff\n\015
()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\
\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)?(?:[^
(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\\[\]\000-
\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\\[^\x80-\xff][^\\\x80-\xff\
n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|
\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))
[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff
\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\x
ff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(
?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\\[\]\
000-\037\x80-\xff])|"[^\\\x80-\xff\n\015"]*(?:\\\[^\x80-\xff][^\\\x80-\
xff\n\015"]*)*")[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\x
ff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)
*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*)*@[\040\t]*(?:\([^\\\x80-\x
ff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-
\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)
*(?:[^(\040)<>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\\[\
]\000-\037\x80-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|\\\[^\x80-\xff])*\]
)[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-
\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\x
ff\n\015()]*)*\)[\040\t]*)*(?:\.[\040\t]*(?:\([^\\\x80-\xff\n\015()]*(
?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]*(?:\\\[^\x80-\xff][^\\\x80
-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)*\)[\040\t]*)*(?:[^(\040)<
>@,;:".\\\\[\]\000-\037\x80-\xff]+(?![^(\040)<>@,;:".\\\\[\]\000-\037\x8
0-\xff])|\\[(?:[^\\\x80-\xff\n\015\\[\]]|\\\[^\x80-\xff])*\])[\040\t]*(?:
\([^\\\x80-\xff\n\015()]*(?:(?:\\\[^\x80-\xff]|\([^\\\x80-\xff\n\015()]
*(?:\\\[^\x80-\xff][^\\\x80-\xff\n\015()]*)*\))[^\\\x80-\xff\n\015()]*)
*\)[\040\t]*)*)*>)

En dat deze regexp nog geeneens rekening houdt met geneste comments?
Zie ook http://www.faqs.org/rfcs/rfc822.html

(Of voor meer info: http://www.perlmonks.org/?node_id=393804 )

[marty]

-NMe- schreef op dinsdag 04 oktober 2005 @ 12:44:

PHP:

(strlen($email)!=0)

is gelijk aan:

PHP:

!empty($email)

Toch niet.
Als $email een spatie bevat is de strlen() groter dan 0, maar beschouwd empty() 'm toch als leeg. Die met strlen() wordt dan dus True en die met empty() wordt False. En True != False

MUBA schreef op dinsdag 04 oktober 2005 @ 13:23:
Jullie weten dat een regexp om ondersteuning te bieden aan bijna alle geldige e-mail adressen er als volgt uit ziet?
[knip]

Nooit geweten .. Ik gebruik al jaaaren deze:

PHP:

if (!preg_match("/(\w+\-*)\@{1}(\w+\-?\w+)(\.\w+\-?\w+)*(\.{1}\w{2,4})$/", $_POST['email']))
{
    // error
}

En die heeft me eigenlijk nog nooit in de steek gelaten voor zover ik weet.
Wat zou hier dan aan mankeren volgens jou?

[ Voor 6% gewijzigd door marty op 04-10-2005 14:44 ]

[Olaf van der Spek]

marty schreef op dinsdag 04 oktober 2005 @ 14:44:
Wat zou hier dan aan mankeren volgens jou?

Matched .museum wel?

[Michali]

marty schreef op dinsdag 04 oktober 2005 @ 14:44:
[...]


Toch niet.
Als $email een spatie bevat is de strlen() groter dan 0, maar beschouwd empty() 'm toch als leeg. Die met strlen() wordt dan dus True en die met empty() wordt False. En True != False

Ik heb het even getest met dit:

PHP:

<?

$var = " ";
var_dump(empty($var));

?>

En dat geeft bool(false) terug hier. Beschouwt hem toch niet als leeg dus.

[ReseTTim]

ik ben net doorverwezen vanuit mijn topic en ik zie dat ik weer een andere mail adres check heb.

PHP:

function ValidateMail($email) {
 if (!eregi("^[0-9a-z]([-_.]?[0-9a-z])*@[0-9a-z]([-.]?[0-9a-z])*\\.[a-wyz][a-z](g|l|m|pa|t|u|v)?$",$email)){;
  return 0;
      }
      else{
  return 1;
 }
}

eerlijk gezegd weet ik niet wat die (g|l|m|pa|t|u|v) doet..

[marty]

@-NMe- & Michali: oops, ik bedoel 0 ipv " "
@Olafvdspek: tering, is dat weer nieuw? Nouja, afgezien van de .museum dan.

[ Voor 75% gewijzigd door marty op 04-10-2005 14:56 ]

[danslo]

http://www.phpfreakz.nl/artikelen.php?aid=106&page=1

Lees die eens door Staat heel veel interessante info in, inclusief oplossingen, top tutorial!

[Arnout]

ReseTTim schreef op dinsdag 04 oktober 2005 @ 14:51:
[...]
eerlijk gezegd weet ik niet wat die (g|l|m|pa|t|u|v) doet..

Dat is om de laatste letters te matchen, zo te zien niet volledig, info komt er zo niet doorheen.

doe dan: (|l|m|t|u|v|f|ro |fo|op|pa|me|seum|cal)

[ReseTTim]

Arnout schreef op dinsdag 04 oktober 2005 @ 15:00:
[...]

Dat is om de laatste letters te matchen, zo te zien niet volledig, info komt er zo niet doorheen.

doe dan: (|l|m|t|u|v|f|ro |fo|op|pa|me|seum|cal)

fo is voor info..
maar mis je idd wat hier boven gesuggereerd word niet *.co.uk

heb op een pagina gevonden:

$_POST['email'] = preg_replace("/\r/", "", $_POST['email']);
$_POST['email'] = preg_replace("/\n/", "", $_POST['email']);

dit is voor de header zeggen ze.. ook las ik nog iets over Bcc kan je dat dan ook niet erbij zetten voor preg_replace? of gaat er dan een hoop mis?

bijv.:
$_POST['email'] = preg_replace("/bcc:/", "", $_POST['email']);

daarbij is in mijn geval 'email' alle tekst die een gebruiker mee stuurd.. moet deze dan niet gewijzigd worden naar 'header' of ben ik gewoon de weg kwijt?

[edit]

toch de weg kwijt.. heb alles van $email, $naam etc
behalve: mail($recipient, $subject, $mail_body, $header);

de rest heb ik dus naar $_POST[''] gewijzigd..

maar ik ben nu ffies kwijt waar ik die bovenste post moet plaatsen met preg_replace..

[ Voor 32% gewijzigd door ReseTTim op 04-10-2005 15:22 ]

[NMe]

marty schreef op dinsdag 04 oktober 2005 @ 14:44:
Toch niet.
Als $email een spatie bevat is de strlen() groter dan 0, maar beschouwd empty() 'm toch als leeg. Die met strlen() wordt dan dus True en die met empty() wordt False. En True != False

Klopt, maar een spatie als mailadres lijkt me sowieso ongewenst, en een empty-check gaat altijd sneller dan een regexp.

[DirkT]

crisp schreef op zaterdag 01 oktober 2005 @ 14:20:
[...]

.museum bijvoorbeeld

TheBorg schreef op zaterdag 01 oktober 2005 @ 14:29:
Inderdaad, en natuurlijk 2 puntjes voor bijv. [e-mail]

meerdere punten was hier al bekend en werd al afgevangen, maar museum is echt nieuw voor me, thnx. Ga ik die er ook even inbakken

voor de liefhebber "alle" toplevel domains lijstje:
http://www.techdictionary.com/domainlist.html
http://en.wikipedia.org/w...nternet_top-level_domains

[ Voor 20% gewijzigd door DirkT op 04-10-2005 16:44 ]

[Dutchmega]

PHP:

preg_match("!^([[:alnum:]_.-]+)@([[:alnum:]_.-]+)\.([a-z]{2}|ac.uk|co.uk|com|net|edu|gov|org|travel|aero|biz|coop|info|museum|name|pro|travel)$!is", $str)

Ik heb het wat herschreven na het lezen van deze topic

[Erkens]

Dutchmega schreef op woensdag 05 oktober 2005 @ 20:45:

PHP:

preg_match("!^([[:alnum:]_.-]+)@([[:alnum:]_.-]+)\.([a-z]{2}|ac.uk|co.uk|com|net|edu|gov|org|travel|aero|biz|coop|info|museum|name|pro|travel)$!is", $str)

Ik heb het wat herschreven na het lezen van deze topic

waarom heb je ac.uk en co.uk los genoemd terwijl die ook validaten als je die eruit laat? (overigens heb je dergelijke constructies ook in andere landen en zijn er wel meer combinaties mogelijk)

[CH4OS]

Ik snap alleen niet, waarom jullie regular expressions gebruiken, bedoel, je kan toch middels htmlentities / htmlspecialchars er toch ook al voor zorgen dat injection niet meer kan?

OK, je krijgt dan een zut gare code te zien, maar dat kan je ook weer weg filteren met str_replace();
Gooi je hetgeen je weggefilterd wil hebben in een array, die geef je op bij str_replace en natuurlijk de bron, krijg je zoiets als:

PHP:

$filter = array("\n", "\r"); // Plus eventuele andere dingen waar je op wilt filteren... :)
$name = str_replace($filter, htmlentities($_POST['name']));
$email = str_replace($filter, htmlentities($_POST['email']));

[ Voor 7% gewijzigd door CH4OS op 05-10-2005 21:18 ]

[Erkens]

GJ-tje schreef op woensdag 05 oktober 2005 @ 21:16:
Ik snap alleen niet, waarom jullie regular expressions gebruiken, bedoel, je kan toch middels htmlentities / htmlspecialchars er toch ook al voor zorgen dat injection niet meer kan?

het mooie van die reguliere expressies is dat je meteen weet dat het e-mail adres ongelig moet zijn omdat deze niet kan volgens de syntax (rfc) dus waarom dan nog meer moeite doen? gewoon een error richting de gebruiker terug en klaar.

[CH4OS]

Erkens schreef op woensdag 05 oktober 2005 @ 21:23:
het mooie van die reguliere expressies is dat je meteen weet dat het e-mail adres ongelig moet zijn omdat deze niet kan volgens de syntax (rfc) dus waarom dan nog meer moeite doen? gewoon een error richting de gebruiker terug en klaar.

Een RFC staat (voor zover mij bekend) voor Request For Change.
Het kan dus maar zo zijn, dat (sommige) RFC's niet doorgevoerd worden, dus echt een 'standaard' of 'syntax' vormen RFC's niet, aangezien het (uiteraard vertaald) 'Verzoek Voor Verandering' betekend...

Wat bedoel je trouwens met een emailadres die niet kan? Want er zijn genoeg 'catch all' domeinen op het web te vinden...

[ Voor 18% gewijzigd door CH4OS op 05-10-2005 21:28 ]

[Olaf van der Spek]

GJ-tje schreef op woensdag 05 oktober 2005 @ 21:27:
[...]
Een RFC staat (voor zover mij bekend) voor Request For Change.

Nope: http://www.google.com/search?q=define:rfc

[CH4OS]

OlafvdSpek schreef op woensdag 05 oktober 2005 @ 21:28:
Nope: http://www.google.com/search?q=define:rfc

Request For Comments... Hmmm... Die term kende ik nog niet, maar alsnog maakt het nog geen standaard of een syntax, want dit is (ook weer letterlijk vertaald) Verzoek Voor Commentaar, schiet je dus ook niet veel mee op. RFC als Request For Change bestaat wel, tenminste, als een term in ITIL (Helpdesk) Vandaar dat ik het enigsinds herkende

[ Voor 3% gewijzigd door CH4OS op 05-10-2005 21:31 ]

[Erkens]

GJ-tje schreef op woensdag 05 oktober 2005 @ 21:27:
[...]
Een RFC staat (voor zover mij bekend) voor Request For Change.
Het kan dus maar zo zijn, dat (sommige) RFC's niet doorgevoerd worden, dus echt een 'standaard' of 'syntax' vormen RFC's niet, aangezien het (uiteraard vertaald) 'Verzoek Voor Verandering' betekend...

Request for Comment.

Als iedereen zo dacht als jij nu dan was internet niet wat het nu is (hoewel Microsoft zijn best aan het doen is )

zie o.a. http://www.faqs.org/rfcs/rfc822.html

[CH4OS]

Erkens schreef op woensdag 05 oktober 2005 @ 21:31:
Als iedereen zo dacht als jij nu dan was internet niet wat het nu is (hoewel Microsoft zijn best aan het doen is )

zie o.a. http://www.faqs.org/rfcs/rfc822.html

Nah, ik doe geen poging om het te veranderen hoor, ik vertel ook alleen maar wat ik dacht dat het was, omdat ik die term al eens heb gehad op mijn vorige school, bij het vak over ITIL (Helpdesk)

Waarom zou ik het willen veranderen anywayz, mogen wat mij betreft de experts wel doen, iets wat ik niet ben gelukkig...

[Erkens]

Maar iig zijn de meeste RFC's gewoon een standaard. Althans daar mag je vanuit gaan

[FireFoz]

Kleine kick.

Bij mij is vanacht ongeveer hetzelfde gebeurt. Nou ja niet bij mij, maar bij iemand die ik host.

PHP:

$Antwoord = $_POST['Antwoord'];
$email = $_POST['Email'];

$onderwerp = "onderwerp";
$myname = "naam";
$myemail ="mijn@email";
$Antwoord = "U schreef:

$Antwoord";

mail("$email", "$onderwerp", "$Antwoord", "From: $myname<$myemail>\nReturn-path: $myemail");

Ik heb wegens veiligheids redenen sommige code weg gehaald en waarden veranderen (onderwerp e.d.), maar het principe was zoals deze code.

Ze hebben dus bij $Antwoord nieuwe headers ingevuld met een hele boel BCC adressen, en een spam bericht.

Bij hun email adres hadden ze niks raars ingevuld.

Wat ik nou wil weten, is hoe ik dit kan voorkomen. Stel dat ik het email adres goed filter op geldige waarden... hoe kan ik dan voorkomen dat ze iets in de body zetten dat php/mail() vervolgens als headers ziet?

Ze hebben dit ingevuld bij $Antwoord:

PHP:

Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
bcc: [e-mail]


spam bericht

Is het controleren op regels als "MIME-" en "Content-Type" voldoende? Lijkt me niet he... ? Maar wat dan wel? Want ik zie hier veel discussie over het controleren van het email adres, maar niet van de body zelf.

[NMe]

In $antwoord kun je helemaal geen headers zetten, want als het goed is worden er voordat $antwoord in die mail wordt gezet eerst nog twee regeleindes toegevoegd, wat betekent dat de header is afgelopen. Ze zullen dus eerder geïnjecteerd hebben in één van de andere variabelen. Komen het email adres of subject niet ook van het formulier af?

[TheBorg]

Ik denk dat het afdoende is om de invoervelden te controleren op 'MIME-Version' en 'Content-Type'?

[Voutloos]

-NMe- schreef op woensdag 16 november 2005 @ 14:28:
Komen het email adres of subject niet ook van het formulier af?

PHP:

$Antwoord = $_POST['Antwoord'];
$email = $_POST['Email'];

Ja dus.

Eerlijk gezegd zie ik het probleem niet zo, in dit topic staan al 40 regexjes die deze 2 variabelen kunnen controleren. Waarom zou er voor FireFoz een nieuwe oplossing nodig zijn, hij moet gewoon niet domweg de POST variabelen ongecontroleerd verder verwerken.

[ Voor 3% gewijzigd door Voutloos op 16-11-2005 14:48 ]

[ultimasnake]

Je kan toch ook de referrer nakijken? komt het niet via jouw server.. niet gebruiken? (en dan desnoods een mailnaar jou laten vesrturen met de referrer daar in zodat je weet vanaf welke site ze proberen die van jou te misbruiken?)

[FireFoz]

Voutloos schreef op woensdag 16 november 2005 @ 14:48:
[...]

PHP:

$Antwoord = $_POST['Antwoord'];
$email = $_POST['Email'];

Ja dus.

Eerlijk gezegd zie ik het probleem niet zo, in dit topic staan al 40 regexjes die deze 2 variabelen kunnen controleren. Waarom zou er voor FireFoz een nieuwe oplossing nodig zijn, hij moet gewoon niet domweg de POST variabelen ongecontroleerd verder verwerken.

Alle regexen die hier staan (tenzij ik er overheen gelezen heb ) zijn om email adressen te valideren. Deze regexen kan ik natuurlijk niet op de body toepassen.

$Antwoord is zeg maar de body van de email, die ook via het formulier wordt ingevuld.

Ik weet dat dit gare en brakke code is, maar het is ook niet mijn code. Ik zie alleen zo 123 niet waarom ze dmv de body veranderen de headers hebben kunnen veranderen.

De referer checken is geen goed idee. zo'n 15% van de browsers geeft geen header mee en sommige firewalls blocken de header. Die zouden dan geen gebruik van het formulier kunnen maken.

[NMe]

FireFoz schreef op woensdag 16 november 2005 @ 15:10:
Alle regexen die hier staan (tenzij ik er overheen gelezen heb ) zijn om email adressen te valideren. Deze regexen kan ik natuurlijk niet op de body toepassen.

$Antwoord is zeg maar de body van de email, die ook via het formulier wordt ingevuld.

$Antwoord is dus tevens niet wat je wil checken, want daar gaat het niet fout. Zoals ik in mijn vorige post ook al zei: voordat $Antwoord in een mailtje wordt afgedrukt, wordt een dubbele \r\n erin gezet, wat het einde van de headers betekent. De enige plaats waar je headers kunt injecteren is in die $email variabele. Die zul je dan ook moeten checken, en daar zijn, zoals al eerder opgemerkt, in dit topic meer dan genoeg regexps voor gegeven.

[Anoniem: 156183]

Wat je ook zou kunnen doen is op host checken (ook al raad ik het niet aan omdat het erg langzaam is)..
In dit geval kun je het ong. zo doen:

code:

$host = explode( "@", $_POST['email'] );
//Nog aan het zoeken je moet met fsock()  en fopen()  werken..

Angel

[FireFoz]

-NMe- schreef op woensdag 16 november 2005 @ 15:15:
[...]
een dubbele \r\n erin gezet, wat het einde van de headers betekent.

Zo dus?

PHP:

$Antwoord = "\r\n\r\n$Antwoord";

[ Voor 20% gewijzigd door FireFoz op 16-11-2005 15:43 ]

[Voutloos]

Het punt is dat je dat nooit zelf hoeft te doen en het dus automagisch goed gaat. Vergelijk het met headers aanpassen met php terwijl je al output richting gebruiker gestuurd hebt.

Tussen headers en body staat dus altijd "\r\n\r\n".

Overigens is dit gewoon vraag over de definitie van header en body en hun scheiding, iets dat je ook in een RFC kan nalezen. In RFC's wordt "\r\n" aangegeven als CRLF (==Carriage Return/Line Feed)

[ Voor 31% gewijzigd door Voutloos op 16-11-2005 15:50 ]

[TheBorg]

Volgensmij heeft het controleren op '\r\n' totaal geen zin, omdat er om te spammen gebruik wordt gemaak van multi-part messages (d.m.v. een message in een message).

[ Voor 5% gewijzigd door TheBorg op 16-11-2005 15:48 ]

[NMe]

FireFoz schreef op woensdag 16 november 2005 @ 15:40:
Zo dus?

PHP:

$Antwoord = "\r\n\r\n$Antwoord";

Ik zal het even heel simpel zeggen.

Laat $Antwoord met rust, en ga je met $email bezig houden. $Antwoord kan niet gebruikt worden voor header-injectie, $email wel.

[FireFoz]

-NMe- schreef op woensdag 16 november 2005 @ 15:49:
[...]

Ik zal het even heel simpel zeggen.

Laat $Antwoord met rust, en ga je met $email bezig houden. $Antwoord kan niet gebruikt worden voor header-injectie, $email wel.

Maar in $Antwoord staat een nieuwe message:

PHP:

U schreef:

Content-Type: text/plain; charset=\"us-ascii\" 
MIME-Version: 1.0 
Content-Transfer-Encoding: 7bit 
bcc: [e-mail] 


-spam bericht-

-de rest van het originele bericht dat eigenlijk verstuurd had moeten worden-
 

Zo kwam de spam-report binnen. Dus ze hebben toch echt in $Antwoord gezet, anders zou er nooit "U schreef:" boven staan, en text die door het script werd toegevoegd onder het spam bericht.
Volgensmij is het een message in een message ofzo... zoals the borg zegt?
Voor zo ver ik weet was heel $email leeg

[TheBorg]

Ik heb net dit doorgelezen en het lijk inderdaad het beste te zijn alle invoervelden op 'Content-Type' en 'MIME-Version' te controleren (case-unsensitive natuurlijk).

[FireFoz]

TheBorg schreef op woensdag 16 november 2005 @ 16:46:
Ik heb net dit doorgelezen en het lijk inderdaad het beste te zijn alle invoervelden op 'Content-Type' en 'MIME-Version' te controleren (case-unsensitive natuurlijk).

Volgensmij ook. Wat -NME- zegt is dus niet waar, dat je de body niet hoeft te controleren, want daarmee kan het net zo goed.

Ik heb momenteel een logger gemaakt op de plaats van de file, zodat ik , als ze het nog een keer pboeren, precies kan zien wat ze doen.

[NMe]

FireFoz schreef op woensdag 16 november 2005 @ 17:13:
Volgensmij ook. Wat -NME- zegt is dus niet waar, dat je de body niet hoeft te controleren, want daarmee kan het net zo goed.

Er staat toch "U schreef:" voor, of niet dan? Hoe kan het dan in godsnaam onderdeel van een header zijn? Je header is daar allang afgelopen: dat ze proberen om daar headers te injecteren wil nog niet zeggen dat dat ook de plaats is waar het gebeurt. Misschien hebben ze ook wel dezelfde headers in $email geïnjecteerd... Maar goed, als je mijn tips niet ter harte wil nemen is dat jouw probleem, niet het mijne.

[FireFoz]

-NMe- schreef op woensdag 16 november 2005 @ 17:32:
[...]

Er staat toch "U schreef:" voor, of niet dan? Hoe kan het dan in godsnaam onderdeel van een header zijn? Je header is daar allang afgelopen: dat ze proberen om daar headers te injecteren wil nog niet zeggen dat dat ook de plaats is waar het gebeurt. Misschien hebben ze ook wel dezelfde headers in $email geïnjecteerd... Maar goed, als je mijn tips niet ter harte wil nemen is dat jouw probleem, niet het mijne.

Dat wil ik wel, en ik controlleer $email ook wel nu, maar ik denk dat je er daarmee nog niet bent
Dus dat de body zelf ookg econtrolleerd moet worden.
Ik heb momenteel een logger geplaatst die alles logt indien ze het nogmaals proberen (hope so).
Als dat gebeurt zal ik dat wel ff posten hier.

[Voutloos]

Voor een multipart mailtje moet er in de echte header iets als Content-Type: multipart/mixed; boundary=\"===============1104808547==\" geïnjecteerd worden.

Als je je headers dus goed controleert, is een multipart stukje in de body dus niet schadelijk.

Op zich kan het geen kwaad om alles te controleren en als je bijvoorbeeld een contact-form zo controleert zal ook geen echte klant erover vallen dat hij geen header keywords kan gebruiken in zijn tekstje. Maar het kan ook geen kwaad om te begrijpen hoe bepaalde protocollen werken, zodat je ook niet op spoken gaat jagen.

[FireFoz]

Eerste resultaat van de logger:

code:

Array
(
    [naam] => took
Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: an
bcc: [e-mail]

f0c4eb2ec56c300ac3d9d5553dbfdc00
.

)

$naam is dus het eerste veld dat in $antwoord wordt verwerkt, en NIET de het email adres waar naar toe verstuurd wordt...

[ Voor 22% gewijzigd door FireFoz op 16-11-2005 21:02 ]

[Gomez12]

Simpele vraag, in de voorbeeld code wordt $email gewoon direct in de header gezet ( =fout ) zonder error checking, de variabele $naam kan ik helemaal niet in de voorbeeld code terugvinden.
Wat moet de voorbeeld-code voorstellen???
Een voorbeeld van hoe je geen mails moet versturen wat geen relatie met jouw werkelijke probleem heeft ofzo???

Maar ok OT, in je voorbeeld staat : U schreef ....
is $naam hierbij hetzelfde als U ( dus de eerste tekst die in de body verschijnt ) of staat er iets voor $naam???

[FireFoz]

In het orignele script, wordt $Antwoord opgebouwd uit verschillende variabelen, zoals $naam, $adres, etc.

Maar, er komt wel eerst "U Schreef:" voor. Dus:

code:

$Antwoord = "U schreef:

naam: $naam
adres: $adres";

Zo iets. In elk geval komt het er dus op neer dat dat gene waar ze de data invoegen, in de body is, en dat er al "text" vooraf in staat ("U schreef") en text er na.
Ik weet alleen niet of dat wat ik nu gelogt heb precies is wat ze vorige keer gedaan hebben...

[T-MOB]

Volgens mij ben je al veilig als je elk veld dat in een header komt controleert op linebreaks. Als de input van je eigen webapp komt levert dat sowieso geen probleem aangezien je alleen in een textarea linebreaks kan typen en je - mag ik hopen - geen textarea gebruikt voor afzenderadres en/of naam.

In de mail body zelf kunnen geen subberichten worden geïnjecteerd aangezien het protocol specificeert dat de headers zijn afgelopen na de eerste dubbele \r\n. Alles wat daarna komt is simpelweg messagebody, anders zou je ook niet kunnen e-mailen over e-mail-headers Dat wordt iets anders als je multipart e-mail gaat versturen. Als je dat met PHP's mail functie doet zou je echter voldoende van het mailprotocol moeten weten om het ueberhaupt voor elkaar te krijgen en dus ook om security-issues te beoordelen.

[Erkens]

T-MOB schreef op donderdag 17 november 2005 @ 02:43:
Volgens mij ben je al veilig als je elk veld dat in een header komt controleert op linebreaks. Als de input van je eigen webapp komt levert dat sowieso geen probleem aangezien je alleen in een textarea linebreaks kan typen en je - mag ik hopen - geen textarea gebruikt voor afzenderadres en/of naam.

maar als kwaadwillende user kan ik natuurlijk altijd zelf een post doen met een zooi linebreaks, op welk veld dan ook

[Olaf van der Spek]

FireFoz schreef op woensdag 16 november 2005 @ 20:59:
Eerste resultaat van de logger:

Kun je de code van die logger posten?
En ook de code die de mail verstuurd?

[T-MOB]

Erkens schreef op donderdag 17 november 2005 @ 06:32:
[...]
maar als kwaadwillende user kan ik natuurlijk altijd zelf een post doen met een zooi linebreaks, op welk veld dan ook

Dat snap ik ook wel, ik bedoelde dat het checken geen problemen oplevert voor de normale werking van de site, itt tot het afvangen van woordencombinaties die ook in headers voorkomen.

[Hydra]

ultimasnake schreef op woensdag 16 november 2005 @ 15:04:
Je kan toch ook de referrer nakijken? komt het niet via jouw server.. niet gebruiken? (en dan desnoods een mailnaar jou laten vesrturen met de referrer daar in zodat je weet vanaf welke site ze proberen die van jou te misbruiken?)

Referrers worden gestuurd door de browser, en zijn dus te faken.