Ob es nun ein Programmierfehler war, lässt sich ohne den Code nicht feststellen. Möglicherweise war es auch ein Konfigurationsfehler oder ein Sicherheitsproblem (bzw. letzteres durch ersteres), das diesen Missbrauch des Servers ermöglicht hat.

Mal davon abgesehen, dass in dem Code-Ausschnitt einiges Zeug ist, dass scheinbar nicht benutzt wird (etwa der Teil zum Versenden von hochgeladenen Dateien und der Multipart-Mail-Teil), scheint mir das Script nicht für Parameter-Injection bei register_globals=on anfällig zu sein. Ein Risiko bei der ohnehin sehr fragwürdigen Prüfung der manuell eingetragenen (und damit als gültig annehmbaren) Email-Adresse, die, falls doch ungültig, mit einem recht unsinnigen unset($email_address) quittiert wird, schließe ich auch aus.

Möglicherweise hat nur ein Spammer deine Domain als (natürlich gefälschte) Absenderadresse eingetragen und die unzustellbaren Emails an nicht existierende Postfächer sind entsprechend zu deinem Catch-All deiner Domain gebouncet. So ganz sieht mir die o.g. Mail allerdings auch wieder nicht danach aus.

Zitat von »Bluefake«

Also auf Deutsch: Das Skript – so stümperhaft es nach Deinen Angaben auch von den Programmierern gecodet wurde – war nicht schuld?

Unter Vorbehalt: ja.

Zitat von »Y0Gi«

Unter Vorbehalt: ja.

Was passiert, wenn man in die Headerzeilen ein neues To: Einfügt?
Oder ein BCC: oder ein cc: ?

Wird das rausgefiltert?
[edit]
also von der mail FUnktion her selber, in den Header kann man das afaik ansonsten einfügen...

Guter Einwand,

könnte durchaus problematisch sein. Zudem bin ich nicht sicher, inwieweit die Parameter für mail() nach z.B. eben Zeilenumbrüchen gefiltert werden - bei PHP würde ich nicht unbedingt davon ausgehen...

Wenn ich die Zeit finde, probiere ich das möglicherweise.

Ich bin nicht sicher, ob das Überschreiben, z.B. mit einer neuen "To:"-Zeile, möglich ist. Eher würde diese ergänzt. In dem Fall (oder auch bei CC: und BCC müsstest du aber ja auch jeweils eine Kopie der Mail erhalten haben. Hast du das? Obiger Schilderung nach ja nicht.

Du könntest zudem Mal die Access-Logfiles aus dem problematischen Zeitraum besorgen, die Zugriffe auf dein Kontakt-Formular-Script herausfiltern und dann darin nach per URL (GET) übergebenen Parametern suchen. Vielleicht sind ja Treffer dabei.

Zitat von »Y0Gi«

Guter Einwand,

	Quellcode
1	$headers="From:$form_element1\r\n" [...]

könnte durchaus problematisch sein. Zudem bin ich nicht sicher, inwieweit die Parameter für mail() nach z.B. eben Zeilenumbrüchen gefiltert werden - bei PHP würde ich nicht unbedingt davon ausgehen...

und dazu kommt ja:
$form_element1 = $_POST['form_element1'];

d.h. er nimmt da jede beliebige Postvariable. Was leider bedeuted, dass er in den Logs wohl nix finden wird
[€dit]

Da kann man also ohne Probleme weitere Empfänger angeben...

Zitat von »Clark«

und dazu kommt ja:
$form_element1 = $_POST['form_element1'];

d.h. er nimmt da jede beliebige Postvariable. Was leider bedeuted, dass er in den Logs wohl nix finden wird

Ist mir durchaus klar. Aber vielleicht hat es der Fiesling ja doch zufällig über GET versucht oder, weil einfacher zu programmieren, die Parameter automatisiert per GET übergeben.

Edit: Wenn ich allerdings genau hinschaue, dürfte GET bei $_POST wenig wirken... *patsch* :
Aber: Könnte ja trotzdem wer versucht haben
Und: Anhand der Zugriffszahlen auf das Kontaktformular lässt sich auch möglicherweise in etwa ersehen, ob das wirklich für o.g. Mails missbraucht wurde. Denn wenn da in der Zeit nur fünf Zugriffe waren, aber 100 Mails rausgingen, hat es wohl daran nicht gelegen.

In der CT war vor einigen Monaten mal ein Artikel (22/05) zum Thema sicherer Formmailer, könnte evtl interessant sein.

Desweiteren würde ich Dir den Kauf von "PHP-Sicherheit - PHP/MySQL-Webanwendungen sicher programmieren"" nahelegen (ISBN 3-89864-369-7).

Recht gut geschrieben und großteils auch für Leute ohne tiefgehendes Wissen verständlich.

Leider gehörte Sicherheit noch nie wirklich zu den Dingen, auf die bei der Entwicklung von PHP übermäßig viel Wert gelegt wurde.

leuko: Aber vielen Dank für den Buchtipp, hört sich gut an und dpunkt-Werken traue ich da einiges zu.

zum ursprünglichen problem:

Zitat

Sicherheitsleck: Realmac Software hat eine Sicherheitslücke im Kontaktformular-Plug-in für den Web-Editor RapidWeaver geschlossen. Zur Installation müssen Nutzer der Software die Datei in das Verzeichnis /Library/Application Support/Rapid Weaver/ im Home-Ordner verschieben. Der Download (ZIP-Archiv) des
Plug-ins is kostenlos, RapidWeaver selbst ist für 34,95 US-Dollar zuhaben.