Angriffe auf Kontaktformular, jemand versucht spam über contact_us.php Einstellungen

[AnHe]

Seit Freitag Abend habe ich automatisierte Zugriffe auf meine contact_us.php. Aufgefallen ist mir das, weil ich mehrere Mails über das Kontaktformular erhalten habe. Soweit nichts Schlimmes, aber es ist dem Angreifer gelungen, die Kontaktmail nicht nur an mich, sondern auch als Kopie an eine Testadresse zu senden. Damit läßt sich das Formular als Spamschleuder missbrauchen. Offensichtlich hat das ganze aber noch nicht so geklappt, wie es der Angreifer wollte, sonst hätte er nicht das ganze Wochenende bis heute Vormittag weitere Versuche unternommen. Allerdings bin ich besorgt, daß das Kontaktformular tatsächlich mißbraucht werden kann. In einem anderen Forum habe ich von ähnlichen Fällen gelesen. Dort werden ebenfalls Kontaktformulare auf diese Weise "getestet".

Was ich bisher weiß:
- der Angreifer benutzt ein Script oder eine Software, mit der er per POST direkt auf die contact_us.php Daten schickt
- der Angreifer hat den URL einmal genommen (inkl. Session-Id), er benutzt bei jedem POST die gleiche Session-Id
- die Zugriffe finden in größeren Abständen statt (> 30 Minuten, meist 1 Stunde, häufig mehrere Stunden), beginnen Abends und enden am Vormittag.
- für die Zugriffe werden Proxies benutzt. Ich habe u.a. IPs aus Irak, Vereinigte Arabische Emirate, Österreich, Niederlande, USA
- theoretisch funktioniert der Angriff so, daß ein zusätzlicher Mail-Header erzeugt wird und dieser Header die entsprechenden Daten (Adressen, Subject, Text) enthält

Hier sind ein Stück vom Mailheader und ein Eintrag aus dem Logfile:

QUELLTEXT

To: sales@meinedomain.de
Subject: Anfrage an Shopinhaber
From: "rljlyygd@meinedomain.de" <rljlyygd@meinedomain.de>
To: "Shopinhaber" <sales@meinedomain.de>
MIME-Version: 1.0
X-Mailer: osCommerce Mailer
Content-Type: multipart/alternative;
    boundary="=_15c03a197bc9c812630471cca8054f11"
Message-Id: <E74BIXJ-4133mh-00@mailserver.de>
sender-info:123456@7890
Envelope-To: sales@meinedomain.de

--=_15c03a197bc9c812630471cca8054f11
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

rljlyygd@meinedomain.de
Content-Type: multipart/mixed; boundary="===============0999466597=="
MIME-Version: 1.0
Subject: cff2736d
To: rljlyygd@meinedomain.de
bcc: adressevomspammer@aol.com
From: rljlyygd@meinedomain.de

This is a multi-part message in MIME format.

--===============0999466597==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

sbnud
--===============0999466597==--
--=_15c03a197bc9c812630471cca8054f11
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

rljlyygd@meinedomain.de<br>Content-Type: multipart/mixed; boundary=3D=
"=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0999466597=3D=3D"<br>MIME-Ver=
sion: 1.0<br>Subject: cff2736d<br>To: rljlyygd@meinedomain.de<br>bcc:=
adressevomspammer@aol.com<br>From: rljlyygd@meinedomain.de<br><br>This is a=
multi-part message in MIME format.<br><br>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D0999466597=3D=3D<br>Content-Type: text/plain; charset=3D"us-=
ascii"<br>MIME-Version: 1.0<br>Content-Transfer-Encoding: 7bit<br><br>sbnud=
<br>--=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D0999466597=3D=3D--
--=_15c03a197bc9c812630471cca8054f11--

213.132.179.181 - - [05/Sep/2005:00:26:30 +0200] "POST /contact_us.php?action=send&osCsid=5cc972e81aba74fab6c6c95ac978e581 HTTP/1.0" 200 20930 www.meinedomain.de "http://www.meinedomain.de/index.html" "-" "-"

Ich habe mein Kontaktformular modifiziert. Es kann jetzt keine Mails mehr verschicken. Sicher ist Sicher. Ich habe versucht, das, was der Angreifer da per POST an das Formular schickt in einer Datenbank zu speichern. Leider werden zwar inserts gemacht, aber die 3 Felder sind leer. Also habe ich bisher nicht gesehen, was der schickt. Das mit der Datenbank werde ich aber wieder rausnehmen, damit mir der Angreifer nicht noch an der DB rumspielt - vielleicht bekommt der ja jetzt einen Datenbankfehler zu sehen?

Ich benutze das Standard contact_us.php Formular mit den Standard eMailfunktionen des Shops. Deshalb denke ich, daß es alle OSC Shopbetreiber betrifft, wenn das Formular wirklich auf diese Weise angreifbar ist. Entsprechend angreifbare Formulare bzw. Shops lassen sich einfach per Suchmaschine oder Spider finden. Wenn der Angriff bei einem Formular klappt, dann klappt er relativ sicher bei vielen (Ich glaube, es gibt Unterschiede zwischen Unix/Linux und Windows Servern, was das Kodieren der Mailheader angeht).

Ich werde das ganze weiter beobachten und ggf. berichten. Vielleicht geht es heute Abend weiter, vielleicht hat der Angreifer auch lange Weile bekommen. Ein Formular, das immer Erfolg meldet, ist hoffentlich langweilig?

Grüße, Andreas

[infobroker]

Das Thema wird akut.

Vielleicht hilft dir das weiter:

http://www.oscommerce.com/community/contributions,3509

[Iunius]

Hi,
willkommen im Club.

Benenne die Datei um, das hilft soweit schonmal.
Desweiteren könnte man noch die Feldlängen beschränken, die Funktionen umbenennen.
Eine Pflichbestätigung einbauen (ideal wäre Captcha) aber auf Rücksicht der User eher eine Checkbox.



Gruss Dirk

Der Beitrag wurde von Obscur bearbeitet: 05.09.2005 18:07

[ironMIKE]

Ich wuerde den Fix der .com Seite bevorzugen:
In der function tep_mail in includes/functions/general.php die Zeilen zwischen
// STARTFIX
und
// ENDFIX
einfuegen:

QUELLTEXT

 function tep_mail($to_name, $to_email_address, $email_subject, $email_text, $from_email_name, $from_email_address) {
   if (SEND_EMAILS != 'true') return false;
// STARTFIX
   $to_name = preg_replace('/[\n|\r].*/', '', $to_name);
   $email_subject = preg_replace('/[\n|\r].*/', '', $email_subject);
   $from_email_name = preg_replace('/[\n|\r].*/', '', $from_email_name);
// ENDFIX

Weitere Tipps?

Man beachte was diese Spammer inzwischen anrichten:
http://www.google.de/search?sourceid=navcl...546%40aol%2Ecom

10tausende Gästebücher und Komentarfelder total zugehaemmert.

[Sir.K.O.]

Was bewirkt Dein Fix und was bewirkt die oben erwähnte Contrib??

Blick das gerade noch nicht ganz....

[AnHe]

Was bewirkt Dein Fix und was bewirkt die oben erwähnte Contrib??

Blick das gerade noch nicht ganz....

Der Fix filtert die Zeilenumbruchzeichen \r\n bzw. \n aus den e-Mail- und Namensfeldern. Diese Felder werden im Header der Mail verwendet und über diese Felder läßt sich mit diesen Zeilenumbrüchen der Header manipulieren bzw. weitere Header einfügen. Sind die Zeilenumbrüche weg, kann nichts schädliches mehr eingefügt werden.

Grüße, Andreas

[ironMIKE]

Was bewirkt Dein Fix und was bewirkt die oben erwähnte Contrib??

Blick das gerade noch nicht ganz....

Die Contrib laesst nur bekannte Buchstaben für Namen und Betreff zu (schwierig bei internationalen Shops wie meinen, da kommen sehr viele Zeichen vor). Der Functionsfix verhindert die POST-Injection von mehrzeiligen Datensaetzen in Name und Betreff um die Änderungen des Mailheaders zu verhindern.
Für deutsche Shops ist eine Kombination aus beidem das Sicherste (aber keine absolute Sicherheit)

[AnHe]

Die Contrib laesst nur bekannte Buchstaben für Namen und Betreff zu (schwierig bei internationalen Shops wie meinen, da kommen sehr viele Zeichen vor). Der Functionsfix verhindert die POST-Injection von mehrzeiligen Datensaetzen in Name und Betreff um die Änderungen des Mailheaders zu verhindern.
Für deutsche Shops ist eine Kombination aus beidem das Sicherste (aber keine absolute Sicherheit)

Ich habe den Fix in die tep_mail() eingebaut und die contact_us.php umbenannt. Das Umbenennen schützt aber nur vorübergehend, solange bis ein Angreifer das Formular mit dem neuen Namen findet.
Die Funktion finde ich sinnvoll, allerdings muß man da tatsächlich überlegen, welche Zeichen und ggf. Sonderzeichen man zuläßt und wie lang die Eingaben sein dürfen. Wenn man da Fehler macht, verärgert man ggf. Besucher.
Da die Angriffe von einem Bot kommen und somit beim Aufruf der Kontaktseite die Navigations-Historie der Session immer 1 ist, habe ich eine andere einfache Sicherung eingebaut. Ich hatte die Sicherung vor wenigen Tagen gepostet, um zu verhindern, daß die redirect.php von außen aufgerufen wird. Auf die Kontaktseite übertragen sieht das so aus.

QUELLTEXT

   $navigation_depth = sizeof($navigation->path);
   if (tep_validate_email($email_address)) {
     if ($navigation_depth > 1) {
       tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_SUBJECT, $enquiry, $name, $email_address);
     }
     tep_redirect(tep_href_link(FILENAME_CONTACT_US, 'action=success'));
   } else {
     $error = true;

Es wird nur dann eine Mail verschickt, wenn der Benutzer der Session vorher mindestens eine Seite aufgerufen hat. Bei Botbesuchen ist das nicht der Fall, also wird nichts verschickt. Allerdings ist es kein großes Problem, ein Programm zu schreiben, das eine Session erzeugt und diese weiterverwendet. Sich alleine darauf zu verlassen, daß ein Bot keine Session benutzen kann, ist also keine Lösung.
Ich glaube, außer die Eingaben möglichst umfangreich zu prüfen, ist nur ein Captcha sinnvoll. Von Checkboxen würde ich absehen, weil die ein Bot auch ändern könnte.

Grüße, Andreas

[chameleon]

QUELLTEXT

   $navigation_depth = sizeof($navigation->path);
   if (tep_validate_email($email_address)) {
     if ($navigation_depth > 1) {
       tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, EMAIL_SUBJECT, $enquiry, $name, $email_address);
     }
     tep_redirect(tep_href_link(FILENAME_CONTACT_US, 'action=success'));
   } else {
     $error = true;

wenn ich diesen code einfüge, wird keine email versand wenn ich den IE nehme, mit firefox ist es ohne probleme.
ist da ein bug drin, das es mit dem IE nicht geht?

[chameleon]

Verstehe zwar was diese contrie will/macht
http://www.oscommerce.com/community/contributions,3509
weis aber nicht wie ich das in die contact_us rein machen soll

QUELLTEXT

Then anywhere when you need to validate the text like in contact_us $name

add if(valid_str($name, '20'))//or what ever length you want
{ <<<ok to send mail and confirm>>>>>
} else {<<<send to "you messed up" page>>>}
*********************************
$validmask can be changed to any characters you want

kann dabei jemand helfen, bitte.

[Sir.K.O.]

Neue Contrib, eventuell ist die besser bzw umfangreicher:
http://www.oscommerce.com/community/contributions,3534

[Scimitar]

Die Contrib laesst nur bekannte Buchstaben für Namen und Betreff zu (schwierig bei internationalen Shops wie meinen, da kommen sehr viele Zeichen vor). Der Functionsfix verhindert die POST-Injection von mehrzeiligen Datensaetzen in Name und Betreff um die Änderungen des Mailheaders zu verhindern.
Für deutsche Shops ist eine Kombination aus beidem das Sicherste (aber keine absolute Sicherheit)

ganz wichtig für die deutschen shops ist , dass die umlaute noch nicht bei den akzeptierten buchstaben der contrib stehen. Also einfach reinschreiben und gut is!

[AnHe]

Neue Contrib, eventuell ist die besser bzw umfangreicher:
http://www.oscommerce.com/community/contributions,3534

@chameleon
o.g. Code ist Browserunabhängig. Es wird geprüft, ob die aufgerufene Seite die erste in der Session registrierte Seite ist, wenn das zutrifft, dann wurde die Seite per Script aufgerufen (Type-In und Bookmark können wir hier ausschließen). Ich habe mit dem IE eine Mail über mein Kontaktformular geschickt, und die Mail ist bei mir angekommen. Alles andere wäre unlogisch. Versuch mal, ob Du mit Deinem IE was in den Warenkorb legen kannst und der Warenkorb beim nächsten Seitenaufruf im Shop erhalten bleibt. Wenn nicht, dann hast Du ein anderes Problem.

@chameleon
Die Funktion valid_str(...) wird in die general.php im Functions-Verzeichnis eingefügt. Laut dieser Funktion ist ein String nur dann gültig, wenn er nicht länger ist als unter length angegeben und nur die in mask angegebenen Zeichen enthält. Das Problem bei dieser Funktion ist, daß man entscheiden muß, welche Zeichen in Mask übergeben werden, also zugelassen werden. Außer den normalen Buchstaben benötigt man Umlaute, ggf. Akzente, wenn man Zeichen vergißt, dann bekommt der Kunde eine Fehlermeldung, die für den Kunden nicht wirklich nachvollziehbar ist. Damit kann man sich u.U. Kunden vergraulen.

@Sir.K.O.
Dieses Contrib ist auch eine Sammlung von möglichen Abwehrmaßnahmen. Das mit der robots.txt halte ich als Schutzmaßnahme für ungeeignet. Grundsätzlich sollten alle Seiten, mit denen ein Suchmaschinen-Robot nichts anfangen kann/soll per robots.txt ausgeschlossen werden. Selbstverständlich auch die contact_us.php. Das verhindert aber nur, daß die Spider, welche sich an die robots.txt halten, diese Datei nicht indizieren. Vor den Spidern, die sich nicht an die robots.txt halten (und das Ding, das meine contact_us.php angreift, hält sich nicht dran), schützt das nicht.
Grundsätzlich finde ich von dieser Contrib noch das

QUELLTEXT

 //Dont send any injection type mails.
 if (eregi('Content-Type:', $to_name)) return false;
 if (eregi('Content-Type:', $email_subject)) return false;
 if (eregi('Content-Type:', $from_email_name)) return false;
 if (eregi('Content-Type:', $email_text)) return false;

am sinnvollsten, als Ergänzung zu den weiteren Feldprüfungen, die schon gepostet wurden. Alles, was darauf basiert, einen Wert in der Session oder wo auch immer zu speichern und vor dem Absenden zu prüfen, verhindert einen automatisierten Angriff, wie er jetzt auf viele Seiten passiert, aber nicht einen Angriff, wo ein Angreifer die Seite und ggf. Werte analysiert. Hier hilft nur die Prüfung der Feldinhalte und vielleicht die häufige Analyse der eigenen Logdateien. Als Schutz, der über die Prüfung der Feldwerte hinaus geht, finde ich ein Captcha sinnvoll. Als Contrib gibt es das hier: Anti Robot Registration Validation 1.0 + images, ich habe es aber nicht ausprobiert und weiß nicht, ob es genau das ist. So wie es laut Beschreibung scheint, werden hier vordefinierte Bilder verwendet. Die Bilder kann man aber auch zur Laufzeit erzeugen.


Aktueller Zwischenstand:
Nachdem ich meine contact_us.php zusätzlich zu den Feldprüfungen und der Session-Prüfung umbenannt habe, hat der Angreifer das ganze Wochenende die contact_us.php weiter aufgerufen. Irgendwie werde ich aus dem ganzen nicht schlau. Einerseits benutzt der Angreifer wahrscheinlich Proxyserver rund um den Globus, jeder Zugriff kommt aus einem anderen Land. Auf der anderen Seite schickt der Angreifer aber eine Session-Id mit, nach der ich ihn auch hätte blocken können. Erfolg/Misserfolg wird scheinbar nicht kontrolliert. Vielleicht bastelt sich da jemand erst den Exploit zusammen und es funktioniert noch nicht so richtig. Bis der dann fertig ist, sind alle Kontaktformulare zumindest umbenannt.

Grüße, Andreas

P.S. suche Linktauschpartner, bei Interesse bitte PM.

[Henri Schmidhube...]

@AnHe

hast in weiten Teilen Recht.

Den Fix den ich einsetze ist:

QUELLTEXT

1.)    die Datei includes/functions/general.php vom Server runter laden
2.)    Datei mit einem [PHP-]Editor öffnen
3.)    Die Funktion: tep_mail   suchen (ab ca. Zeile 959 )
4.)    Gleich unter der Funktionsdeklaration und der danach folgender Abfrage (    if (SEND_EMAILS != 'true') return false;)
folgendes einfügen:

if (eregi('Content-Type:', $to_name)) return false;
if (eregi('Content-Type:', $to_email_address)) return false;
if (eregi('Content-Type:', $email_subject)) return false;
if (eregi('Content-Type:', $email_text)) return false;
if (eregi('Content-Type:', $from_email_name)) return false;
if (eregi('Content-Type:', $from_email_address)) return false;

$to_name = preg_replace('/[\n|\r].*/', '', $to_name);
$to_email_address = preg_replace('/[\n|\r].*/', '', $to_email_address);
$email_subject = preg_replace('/[\n|\r].*/', '', $email_subject);
$from_email_name = preg_replace('/[\n|\r].*/', '', $from_email_name);
$from_email_address = preg_replace('/[\n|\r].*/', '', $from_email_address);

 

Wichtig sind die preg_replace die keine Zeilenumbrüche zulassen.

Wenn einen die Emails nerven: contact_us.php in contact.php unbenennen und entsprechend im Shop anpassen.

Hinweis: der Fehler betrifft nicht nur osc, sondern ich denke mindestens 50% der Formularfelder die mails versenden im Web. IMHO zum Teil auch ein Implementierungslogikfehler von PHP.



Ich hab eigentlich schon eine Announcement für das deutsche Forum vorbereitet (warte auf das OK vom Harald) und Harald will in den nächsten Tagen updates zur Verfügung stellen.

Gruß Henri

[Ingo Malchow]

Eventuell wäre es auch nett, heraus zu finden, WER hier spammt.
contact_us.php:

QUELLTEXT

 require('includes/application_top.php');

 // 4 neue Zeilen:
 if (!tep_session_is_registered('contact_trigger')) {
   tep_session_register('contact_trigger');
   $contact_trigger = md5(time());
 }

QUELLTEXT

 if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send')) {

wird zu:

QUELLTEXT

 if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send') && $contact_trigger==$HTTP_POST_VARS['trigger'] ) {

QUELLTEXT

 $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_CONTACT_US));

wird zu:

QUELLTEXT

 elseif (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send') && $contact_trigger!=$HTTP_POST_VARS['trigger'] ) {
     tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, 'SPAM-WARNUNG', 'Spam-Versuch durch IP: ' . $_SERVER['REMOTE_ADDR'] . " ?\nReferer: " . $_SERVER['HTTP_REFERER'] . "\nText:\n" . $HTTP_POST_VARS['enquiry'], $name, $email_address);
 }

 $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_CONTACT_US));

und

QUELLTEXT

               <td class="main"><?php echo ENTRY_NAME; ?></td>

zu

QUELLTEXT

               <td class="main"><?php echo ENTRY_NAME . tep_draw_hidden_field('trigger', $contact_trigger); ?></td>

[zickentrainercoa...]

Eventuell wäre es auch nett, heraus zu finden, WER hier spammt.
contact_us.php:

QUELLTEXT

 require('includes/application_top.php');

 // 4 neue Zeilen:
 if (!tep_session_is_registered('contact_trigger')) {
   tep_session_register('contact_trigger');
   $contact_trigger = md5(time());
 }

QUELLTEXT

 if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send')) {

wird zu:

QUELLTEXT

 if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send') && $contact_trigger==$HTTP_POST_VARS['trigger'] ) {

QUELLTEXT

 $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_CONTACT_US));

wird zu:

QUELLTEXT

 elseif (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action'] == 'send') && $contact_trigger!=$HTTP_POST_VARS['trigger'] ) {
     tep_mail(STORE_OWNER, STORE_OWNER_EMAIL_ADDRESS, 'SPAM-WARNUNG', 'Spam-Versuch durch IP: ' . $_SERVER['REMOTE_ADDR'] . " ?\nReferer: " . $_SERVER['HTTP_REFERER'] . "\nText:\n" . $HTTP_POST_VARS['enquiry'], $name, $email_address);
 }

 $breadcrumb->add(NAVBAR_TITLE, tep_href_link(FILENAME_CONTACT_US));

und

QUELLTEXT

               <td class="main"><?php echo ENTRY_NAME; ?></td>

zu

QUELLTEXT

               <td class="main"><?php echo ENTRY_NAME . tep_draw_hidden_field('trigger', $contact_trigger); ?></td>

Warum macht Ihr nicht eine Contrib aus dem Problem und Euren beschriebenen Lösungen. ?

[AnHe]

Eventuell wäre es auch nett, heraus zu finden, WER hier spammt.
contact_us.php:

QUELLTEXT

 require('includes/application_top.php');

 // 4 neue Zeilen:
 if (!tep_session_is_registered('contact_trigger')) {
   tep_session_register('contact_trigger');
   $contact_trigger = md5(time());
 }

...

Die Frage, wer hier spammt stellt sich sicher. Allerdings ist bei jedem Zugriff die IP Adresse anders. Der Spammer benutzt wohl Proxies, die über viele Länder verteilt sind. Damit bekommt man in den Logdateien (bzw. mit Deiner IP-Abfrage) nur die Proxy Adresse. Bei mir kommen u.a. Anfragen aus IQ, IR, NL, DE, US, KR. Ich bin mir sicher, daß es sich dabei aber immer um den gleichen Spammer handelt, weil der URL, der aufgerufen wird, immer der gleiche ist (URL enthält eine Session-Id, die ist immer gleich).
Nun haben wir eine Liste mit IP-Adressen, die theoretisch weiter verfolgt werden können, es müßte eine Anfrage beim Betreiber des jeweiligen Proxy Servers gemacht werden, um die IP-Adresse des Rechners zu bekommen, der den Proxy benutzt hat. Allerdings glaube ich kaum, daß jemand aus IQ mir da eine IP zurück gibt, wenn derjenige überhaupt ein Logfile besitzt.
Wenn sich jemand mit den Adressen befassen will, dann kurz posten, dann suche ich die Adressen aus den Logfiles raus.

Eine andere Frage ist, warum werkelt da jemand an den Kontaktformularen rum. Ich wollte das im letzten Post nur andeuten, damit ich niemanden auf dumme Gedanken bringe. Aber die Vorgehensweise erinnert mich an "Spamming für Dummies" . Vielleicht ist es so, daß es schwieriger ist, einen Mailheader und den gewünschten Inhalt einzufügen, wenn die Mail mit einer Klasse mail.php erzeugt wird, als wenn die Mail in einem Script steht, in der die Werte aus den Globals an die mail() Funktion übergeben werden. Allerdings habe ich den Eindruck, daß da jemand gewaltig am Probieren und Basteln ist. Ich habe gerade mit einem Dienstleister gesprochen, der eben so ein "offenes" Mailformular bei sich und seinen Kunden verwendet hat. Der hat auch "komische Mails" bekommen, zwar viel mehr, aber auch ohne verwertbaren Inhalt. Wenn jemand so eine Aktion durchziehen will, dann wäre es doch eine vielversprechende Vorgehensweise, wenn man:
- Mailformulare mit Spidern sucht -> wurde getan
- die Formulare einer Software zuordnet bzw. nach Aufruf klassifiziert -> wurde nicht oder nicht ausreichend getan
- sich die jeweilige Software (wenn OS oder Demo-Version) besorgt, und auf einem Testsystem solange Angriffe macht, bis es _richtig_ funktioniert (mit dem Quellcode würde man die Lücken unter Umständen direkt rauslesen können)
- dann Mails verschickt

Jetzt ist es für die Aktion in sofern zu spät, daß viele Formulare dicht gemacht wurden, und die Absicherung so unterschiedlich erfolgte (allein in diesem Thread sind viele verschiedene Kombinationen möglich), daß es schwieriger wird, diese Formulare anzugreifen. OK, es wird immer Leute geben, die sich oder Ihrem Kunden einen Shop installieren, die privacy.php als Impressum-Seite verwenden und dann natürlich auch keine Kontaktformulare absichern. Aber auf jeden Fall ist die Fehlerrate beim Kontaktformular-Spamming jetzt größer geworden.

Ich denke aber, daß es keiner ist, der uns nur darauf hinweisen wollte, daß sowas über die Formulare geht. Ich denke, es wäre dem zumindest möglich gewesen, einen Hinweis wie "Your mailform ist unsecure/was hacked..." in die Mail zu schreiben.

Daß jemand über das Einfügen von Headern Spam über die Kontaktformulare verschickt, hätte ich nicht wirklich erwartet. Ich hätte mir eher vorstellen können, daß jemand per Script Spam an den eigentlichen Empfänger des Kontaktformulares schickt. Die Mails vom Kontaktformular werden mit großer Wahrscheinlichkeit gelesen, es gibt eine große Anzahl von Kontaktformularen, das automatische Ausfüllen ist relativ einfach (viel einfacher, als Header einzufügen), es läßt sich nicht so leicht verhindern, weil Anfragen über das Kontaktformular sollen ja trotzdem ankommen. In dem Fall kann man Ingos contact_trigger oder mein Code-Schnipsel, welcher prüft, ob das Mailformular in der Session-Historie das erste ist, verwenden, um den Spam per Formular-Direktaufruf zu verhindern.

Ich hoffe, daß die Ideen nur im Rahmen einer Diskussion zur Vermeidung von Spam und zur Erhöhung der Sicherheit unserer Webseiten verwendet werden.

Grüße, Andreas

[Bergi]

Hy Leute.

Bin neu hier und gerade erst dabei meinen Webshop aufzubauen.

Ist nicht derjenige per Gesetz zur Verantwortung zu ziehen, der die SpamMails verbreitet? Somit bin z.B. Ich dafür verantwortlich, wenn jemand mein Kontaktformular verwendet und darüber Mails verschickt.

Ich glaube wir tun gut daran uns bestmöglich abzusichern.

greez

[Ingo Malchow]

...Somit bin z.B. Ich dafür verantwortlich, wenn jemand mein Kontaktformular verwendet und darüber Mails verschickt...

Korrekt. Deshalb die Aufregung. Außerdem landet der absendende Server ruckizucki auf schwarzen Listen.

Meine Triggerweiche hat zumindest ansatzweise funktioniert.

[amspo]

Hallo,

ist die Codeeingabe aufgrund eines Bildes sicher?
Habe dazu das Contrib eingebaut.

Gruß
Rainer