Kontaktformular Hack / Email Injection

[Anfaenger]

Nach dem SQL Injection Thema bin ich zufällig auf das Email Injection Thema gestossen und muss mir leider wieder Gedanken um die Websicherheit machen.

Ich habe zwei Arten von Kontaktformularen: einmal "User kontaktiert User" und das andere Mal "User kontaktiert Admin". Letzteres ist OHNE Captcha gebaut, jedoch glaube ich nicht, dass ich beim letzten viel Spam kriegen werde, da dieser Teil mit Ajax gebaut ist und sich ohne aktivierten Javascript sich nicht viel tun wird.

Aber zur eigentlichen Frage: Auf dieser Webseite:

http://www.thesitewizard.com/php/protect-script-from-email-injection.shtml

steht, dass man sowas einbauen sollte preg_match , damit es geschützt ist.

Meine Fragen:

1. Wo genau? Mein Kontaktformular besteht aus verschiedenen Bestandteilen, zB Kontakt.php, sendMail.php . Ich habe in beiden PHP Seiten nichts von preg_match gefunden.

2. Den Endeffekt von preg_match habe ich verstanden (=Schutz), aber wie genau das agiert/funktioniert habe ich noch nicht verstanden. Kann mir einer das mal simpel erklären?

[bleicher]

Grüße,
nicht preg_match selbst, sondern das überprüfen ob zeilenumbrüche, die auf versuch zusatzheader reinzuschleusen deuten, da sind.
MFG
bleicher

[Anfaenger]

Grüße,
nicht preg_match selbst, sondern das überprüfen ob zeilenumbrüche, die auf versuch zusatzheader reinzuschleusen deuten, da sind.
MFG
bleicher

Also sowas?

$headers  = 'MIME-Version: 1.0' . "\r\n";
$headers .= 'Content-type: text/html; charset=iso-8859-1' . "\r\n";

Eine andere Frage, was mir gerade einfällt zum Thema SQL Injection:

• geschieht SQL Injection durch Verändern des URL-Feldes oder muss es irgendwo ein Eingabefeld geben. Bei mir können User sich Profile erstellen. Das heißt, muss einer sich erst registrieren, damit er SQL Injection per Eingabefeld betreiben kann?
• gestern habe ich gefragt, ob $_GET["id"] = (int)$_GET["id"]; gegen SQL Injection hilft. Die Antwort war ja. Heute lese ich irgendwo im Netz, dass es weitesgehend hilft. Wenn einer aber Drop Datenbank macht, dann ist die Datenbank trotz dieses GET-String weg...also auch nicht ganz sicher, oder?

[Vinzenz Mai]

Hallo,

• gestern habe ich gefragt, ob $_GET["id"] = (int)$_GET["id"]; gegen SQL Injection hilft. Die Antwort war ja.

Dies ist richtig.

Heute lese ich irgendwo im Netz, dass es weitesgehend hilft.

Dies ist falsch. Nicht weitestgehend. Es hilft. Für diesen speziellen Anwendungsfall. Für den Fall, dass Deine Anwendung einen Integerwert erwartet.
SQL-Injection ist jedenfalls über diesen Parameter *nicht* mehr möglich. Ganz sicher!

Ob es sinnvoll ist, die Daten überhaupt zu verarbeiten, wenn der Inhalt von $_GET['id'] unpassende Zeichen enthält, das ist eine andere Frage.

Bitte lies den Kontextwechsel-Artikel von dedlfix und den entsprechenden Abschnitt zu Integerwerten durch, auf den er Dich hingewiesen hat.

Freundliche Grüße

Vinzenz

[Vinzenz Mai]

Hallo,

Nach dem SQL Injection Thema bin ich zufällig auf das Email Injection Thema gestossen und muss mir leider wieder Gedanken um die Websicherheit machen.
http://www.thesitewizard.com/php/protect-script-from-email-injection.shtml

steht, dass man sowas einbauen sollte preg_match , damit es geschützt ist.

es gibt noch viele andere Möglichkeiten. Es geht um das Entfernen von Zeilenumbrüchen, nicht um die Anwendung von preg_match().

Meine Fragen:

1. Wo genau? Mein Kontaktformular besteht aus verschiedenen Bestandteilen, zB Kontakt.php, sendMail.php . Ich habe in beiden PHP Seiten nichts von preg_match gefunden.

Ja und?

2. Den Endeffekt von preg_match habe ich verstanden (=Schutz),

Nicht preg_match() ist relevant, sondern das Entfernen von Zeilenumbrüchen aus den Werten, die in E-Mail-Header wandern können.

aber wie genau das agiert/funktioniert habe ich noch nicht verstanden. Kann mir einer das mal simpel erklären?

Wenn nicht gerade der komplizierte Folding-Mechanismus gemäß RFC 822 verwendet wird, haben Zeilenumbrüche in den Headern für Absendername und E-Mail-Adresse nichts zu suchen. Normalerweise kommt nach einem Zeilenumbruch der nächste Header und durch einen eingeschmuggelten Zeilenumbruch kann der Angreifer zum Beispiel bcc-Header mit hübschen Empfängerlisten einbauen ...

Wenn in einzeiligen Eingabefeldern Zeilenumbrüche eingegeben wurden, sinkt die Wahrscheinlichkeit, dass ein Mensch das Formular korrekt und in bester Absicht ausgefüllt hat auf einen zu vernachlässigenden Wert. Mit an Sicherheit grenzender Wahrscheinlichkeit war es ein Bot oder jemand in böser Absicht und Du verlierst nichts, wenn Du seine Eingaben einfach verwirfst. Siehe dazu diesen Archivthread.

Ach ja, ohne preg_match() :-)

Freundliche Grüße

Vinzenz

[hotti]

moin,

.. jedoch glaube ich nicht, dass ich beim letzten viel Spam kriegen werde, da dieser Teil mit Ajax gebaut ist und sich ohne aktivierten Javascript sich nicht viel tun wird.

Irrtum. HTTP hat mit Javascript nichts zu tun.

Schönen Tag,
Hotti