[50% OT] Missbrauch von Formularen?
Marcel Normann
Ich bekomme in der letzten Zeit immer wieder Emails in folgendem Format,
welche mit einem Formular auf einer meiner Webseiten erstellt wurden:
URL: sexcjpz@#########.de
Beschreibung: sexcjpz@#########.de
Content-Type: multipart/mixed; boundary=\"===============0352822630==\"
MIME-Version: 1.0
Subject: 2038ad2d
To: sexcjpz@#########.de
bcc: mhko...@aol.com
From: sexcjpz@########.de
This is a multi-part message in MIME format.
--===============0352822630==
Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
jmswsetomn
--===============0352822630==--
Scheinbar wird hier versucht, über den Missbrauch der Formularfelder eine
Multipart-Email zu erzeugen, bzw. andere Empfänger einzuschleusen
(erfolglos). Meine Vermutung: Der BCC-Empfänger existiert tatsächlich und
prüft über diesen Account, ob meinn Script für den Massenversand missbraucht
werden kann: Der String "jmswsetomn" ist nämlich in allen Mails gleich.
Wie Abhilfe zu schaffen ist, ist klar: "Prüfe alle Parameter, traue
niemandem". Da alle meine Formularfelder eigentlich einzeilig sind, würde es
in meinem Fall schon reichen, alle Zeilenumbrüche zu entfernen.
Das ist zwar mehr ein Thema für eine Sicherheitsgruppe, aber ich wollte das
hier mal als Warnung verstanden wissen. Ganz alleine scheine ich nämlich
auch nicht zu sein:
<http://google.de/search?q=mhkoch321%40aol.com>
Gruß, Marcel
Richard Körber
> Ich bekomme in der letzten Zeit immer wieder Emails in folgendem Format,
> welche mit einem Formular auf einer meiner Webseiten erstellt wurden:
Das geschieht schon seit geraumer Zeit. Der Angreifer sucht mit einem
Script verwundbare Mailformulare, testet dabei alles, was nur annähernd
so aussieht, zum Beispiel auch Gästebücher.
Wenn er ein verwundbares Mailscript findet, wird es angeblich sofort zum
Spammen missbraucht. Neben mhkoch321 hat der Typ wohl noch eine Hand
voll weiterer E-Mailadressen zur Verfügung, er scheint außerdem die
Requests über gekaperte Rechner abzusetzen.
Aufgrund der Art, wie sein Script arbeitet, ist Abhilfe ziemlich
einfach: füge in deinem Formular einfach ein Hidden-Feld mit einem
beliebigen Text ein, z. B.:
<input type="hidden" name="foo" value="bar">
Wenn dein PHP-Script dann beim Parameter "foo" einen anderen Wert
bekommt als "bar", ist es wieder der Angreifer, und du kannst den
Request verwerfen.
Bitte teste dein Mailscript auch unbedingt darauf ab, dass man es nicht
durch Anfügen von Headerzeilen austricksen kann!
Grüße
--
:// Richard "Shred" Körber -~- sh...@despammed.com -~-
Tobias Kutzler
> Marcel Normann schrieb:
>
>
>>Ich bekomme in der letzten Zeit immer wieder Emails in folgendem Format,
>>welche mit einem Formular auf einer meiner Webseiten erstellt wurden:
>
>
> Das geschieht schon seit geraumer Zeit. Der Angreifer sucht mit einem
> Script verwundbare Mailformulare, testet dabei alles, was nur annähernd
> so aussieht, zum Beispiel auch Gästebücher.
>
> Wenn er ein verwundbares Mailscript findet, wird es angeblich sofort zum
> Spammen missbraucht. Neben mhkoch321 hat der Typ wohl noch eine Hand
> voll weiterer E-Mailadressen zur Verfügung, er scheint außerdem die
> Requests über gekaperte Rechner abzusetzen.
>
> Aufgrund der Art, wie sein Script arbeitet, ist Abhilfe ziemlich
> einfach: füge in deinem Formular einfach ein Hidden-Feld mit einem
> beliebigen Text ein, z. B.:
>
> <input type="hidden" name="foo" value="bar">
Und was hindert denjenigen, der das Skript missbrauchen möchte, diesen
Parameter mittels POST mitzusenden? Dann ist dieser Parameter wieder
überflüssig!
Ciao,
Tobias
Philipp Wagner
Es macht es schwieriger, da du diesen Parameter ja zufällig generieren
willst und er bei jedem Request anders ist. Sicher ist es nicht
ausgeschlossen, dass sich der Spamversender vorher die richtige ID holt
und dann die Mail versendet, aber wie gesagt, es macht es schwieriger.
Um das automatische Versenden komplett lahmzulegen, wirst du wohl so ein
CAPTCHA-Bild benötigen (z.B. mit Hilfe von
http://pear.php.net/package/Text_CAPTCHA).
Philipp
Tobias Kutzler
> Um das automatische Versenden komplett lahmzulegen, wirst du wohl so ein
> CAPTCHA-Bild benötigen (z.B. mit Hilfe von
> http://pear.php.net/package/Text_CAPTCHA).
>
FULLACK! Denn nur mit dem, was "Maschinen" nicht lesen können, kann man
solche Sachen ausschliessen. Aber es ist nur eine Frage der Zeit, bis es
möglichist, CAPTCHAs zu "lesen". Aber ich denke, dass es schwierig wird,
da diese Grafiken ja auf "pixeliger Verwirrung" beruhen ;-) Ich denke da
nur an OCRs von Scannern, wenn die mal eine alte Buchseite erkennen
sollen...
Ciao,
Tobias
Martin Lacher
> Aber es ist nur eine Frage der Zeit, bis es möglichist, CAPTCHAs zu "lesen".
ist heute schon möglich.
wird bei bestimmten captcha-systemen zum cracken von pr0n-seiten
angewandt. ich weiß aber nicht, ob ein programm dann das bild ließt,
oder den dargestllten string anders ermittelt.
mfg,
martin lacher
Sven Drieling
Hallo Tobias,
> FULLACK! Denn nur mit dem, was "Maschinen" nicht lesen können, kann man
> solche Sachen ausschliessen. Aber es ist nur eine Frage der Zeit, bis es
> möglichist, CAPTCHAs zu "lesen".
Greg Mori, Jitendra Malik, "Breaking a Visual CAPTCHA",, cs.berkeley.
http://www.cs.berkeley.edu/~mori/gimpy/gimpy.html
Beispiele (Bilder) von CAPTCHAs, die vom Computer entziffert werden
können.
IMHO sollte es aber _derzeit*_ für den Schutz reichen überhaupt eine
zusätzlich einzugebene Information in einem Bild zu speichern, die dort
problemlos zu lesen ist also nicht verschnörkelt sein braucht.
Sofern es kein weit verbreitetes Skript ist muss das Spam-Programm
ja erst einmal dahinter kommen, dass ein CAPTCHA vorhanden ist
und im welchen Bild die Information steht. Theoretisch solltes
es also auch schon ein barrierefreier Klartext im HTML-Code tun, sofern
es kein weit verbreitetes Skript ist. Wenn ein Spam-Skript speziell
auf eine Seite zugeschnitten wird, sieht es eh schlecht aus aber
das widerspricht ja zum Glück der möglichst viel, möglichst billig
Spam-Strategie.
Grafische CAPTCHAs sind nicht barrierefrei.
* Die Spirale lässt sich ja im Prinzip beliebig hochschrauben.
Wenn ein Mensch ein CAPTCHA bestehen kann, dann sollte es auch
irgendwann einmal ein Computer können.
tschuess
[|8:)
Ulf Dunkel
> URL: sexcjpz@#########.de
> Beschreibung: sexcjpz@#########.de
> Content-Type: multipart/mixed; boundary=\"===============0352822630==\"
> MIME-Version: 1.0
> Subject: 2038ad2d
> To: sexcjpz@#########.de
> bcc: mhko...@aol.com
> From: sexcjpz@########.de
Falls Dein Formular keinen "Bcc:"-Versand vorsieht, ist der Fall klar.
Du mußt demnach zumindest klarstellen, daß in den Formularfeldern keine
weiteren Daten eingepflegt werden können, als nötig sind. Das Einpflegen
weiterer Empfänger ist ein Klassiker und wird überall dort, wo
Formular-Sicherheit beschrieben wird, auch behandelt.
Ich mache es in meinen Formularen so, daß es linear nur eine From:- und
eine To:-Adresse geben kann. Die From:-Adresse wird aus den Angaben des
Absenders generiert und vor dem weiteren Verarbeiten des Requests an
deren Server auf Plausibilität geprüft. Sobald da aber Dummfug drinsteht
(wie z.B. "From:He...@schlingel.de\r\n\Bcc:mhko...@aol.com"), meldet
mir mein E-Mail-Test, daß diese "eine" E-Mail-Adresse ungültig ist -
Ende von Lustig.
Die "To:"-Adresse meiner Formulare (die mich ja erreichen soll), ist
verklausuliert und kann nicht vom Absender des Formulars verändert oder
erweitert werden.
--
Bis bald / See you soon / A bientôt / Tot ziens / Ghis revido
Ulf Dunkel - invers Software (www.calamus.net)
Ulf Dunkel
> FULLACK!
Nö - falscher Lösungsansatz. Wenn das Problem darin besteht, daß ein
Spammer in einem Formular Daten einpflegen KANN, die dort nicht erwartet
werden und nicht dort hineingehören, dann ist der einzig richtige
Lösungsansatz, daß der Spammer eben dort keine Daten mehr einpflegen
KANN. Die Inhalte von abgesendeten Formularfeldern zu prüfen, geht mit
PHP - und damit ist das Thema wieder ontopic. :-)
Tobias Kutzler
> Falls Dein Formular keinen "Bcc:"-Versand vorsieht, ist der Fall klar.
> Du mußt demnach zumindest klarstellen, daß in den Formularfeldern keine
> weiteren Daten eingepflegt werden können, als nötig sind. Das Einpflegen
> weiterer Empfänger ist ein Klassiker und wird überall dort, wo
> Formular-Sicherheit beschrieben wird, auch behandelt.
>
> Ich mache es in meinen Formularen so, daß es linear nur eine From:- und
> eine To:-Adresse geben kann. Die From:-Adresse wird aus den Angaben des
> Absenders generiert und vor dem weiteren Verarbeiten des Requests an
> deren Server auf Plausibilität geprüft. Sobald da aber Dummfug drinsteht
> (wie z.B. "From:He...@schlingel.de\r\n\Bcc:mhko...@aol.com"), meldet
> mir mein E-Mail-Test, daß diese "eine" E-Mail-Adresse ungültig ist -
> Ende von Lustig.
Aber wer hindert mich daran, Dein Skript mehrmals aufzurufen und dann
eben die Mails hintereinander verschicken zu lassen? Klar, so kann man
verhindern, dass eine Mail gleich an mehrere Adressaten geht, aber den
Missbrauch kann man so nicht sinnvoll verhindern. Das Skript wartet
immer noch, gefüttert zu werden - auch wenn mit nur einer E-Mail
Adresse, was meiner Meinung nach nicht sinnvoll verhindert werden kann...
> Die "To:"-Adresse meiner Formulare (die mich ja erreichen soll), ist
> verklausuliert und kann nicht vom Absender des Formulars verändert oder
> erweitert werden.
>
Da stimme ich Dir zu. So kann man wenigstens verhindern, dass niemand
Mails an andere Leute als an mich/Dich schickt. Leider kann man so nicht
verhindern, selbst mit Spam zugedeckt zu werden. Wenigstens steht die
Mail Adresse nicht im Klartext im HTML und kann von keinem Spider
ausgelesen und dann missbraucht werden.
Ciao,
Tobias
Philipp Wagner
> Hi Tobias.
>
>> FULLACK!
>
>
> Nö - falscher Lösungsansatz. Wenn das Problem darin besteht, daß ein
> Spammer in einem Formular Daten einpflegen KANN, die dort nicht erwartet
> werden und nicht dort hineingehören, dann ist der einzig richtige
> Lösungsansatz, daß der Spammer eben dort keine Daten mehr einpflegen
> KANN. Die Inhalte von abgesendeten Formularfeldern zu prüfen, geht mit
> PHP - und damit ist das Thema wieder ontopic. :-)
Auch wenn dem nicht so ist, dass mit dem Formular andere bespammt werden
können, möchte ich doch auch selbst als Empfänger des Kontaktformulars
darüber nicht unbedingt täglich Spam ins Haus bekommen. Insofern ist der
Lösungsansatz keineswegs falsch, wenn man mal davon ausgeht dass das
Kontakformular funktioniert wie es sollte (d.h. sonstigen
Sicherheitslücken drin hat).
BTW: Wenn's etwas mehr barrierefrei sein soll, gibt's auch noch die
Möglichkeit das CAPTCHA als Audiodatei zu hinterlegen.
Philipp
Ulf Dunkel
> Auch wenn dem nicht so ist, dass mit dem Formular andere bespammt werden
> können, möchte ich doch auch selbst als Empfänger des Kontaktformulars
> darüber nicht unbedingt täglich Spam ins Haus bekommen.
Versteh ich nicht - Den Empfänger des Kontaktformulars brauchst Du ja im
Formular gar nicht offenzulegen. Da hat mit CAPTCHAs nicht viel zu tun.
Oder reden wir jetzt komplett aneinander vorbei?
Ulf Dunkel
> Aber wer hindert mich daran, Dein Skript mehrmals aufzurufen und dann
> eben die Mails hintereinander verschicken zu lassen?
Mann könnte einen IP-Reminder einbauen, der das automatisierte Versenden
von derselben IP rasch hintereinander blockiert.
> Das Skript wartet
> immer noch, gefüttert zu werden - auch wenn mit nur einer E-Mail
> Adresse, was meiner Meinung nach nicht sinnvoll verhindert werden kann...
Es müssen dann immer noch gültige E-Mail-Adressen sein, mit denen
gefüttert wird.
Ist wirklich ein spannendes Thema.
Dirk Haun
> Mann könnte einen IP-Reminder einbauen, der das automatisierte Versenden
> von derselben IP rasch hintereinander blockiert.
Was sich natürlich mit dem Einsatz einer Armee von Spambots oder einer
Reihe von offenen Proxies wieder aushebeln lässt.
> Ist wirklich ein spannendes Thema.
Yep.
bye, Dirk
--
http://spam.tinyweb.net/article.php/form-hacking-attempts
Tobias Kutzler
> Hi Philipp.
>
>> Auch wenn dem nicht so ist, dass mit dem Formular andere bespammt werden
>> können, möchte ich doch auch selbst als Empfänger des Kontaktformulars
>> darüber nicht unbedingt täglich Spam ins Haus bekommen.
>
>
> Versteh ich nicht - Den Empfänger des Kontaktformulars brauchst Du ja im
> Formular gar nicht offenzulegen. Da hat mit CAPTCHAs nicht viel zu tun.
Naja, selbst wenn Deine E-Mail Adresse nicht im Formular zu sehen ist,
dann gibt es ja ein Skript - vorzugsweise PHP, damit wir beim Thema
bleiben ;-) - mit dem Du dann die Mail an Deine E-Mail Adresse
verschickst. Ergo, bekommst Du den Spam, wenn jemand Dein
Kontaktformular zu Spammen missbraucht. Und genau das bzw. das
automatisierte Versenden mittels Bots sollte verhindert werden, indem
man Mechanismen einbaut, die nur ein Mensch interpretieren kann. Solche
zu finden, die auch auf langer Sicht einen Nutzen bringen, dürfte fast
unmöglich sein, da es immer wieder jemanden geben wird, der es schafft,
das auszuhebeln.
Ciao,
Tobias
Tobias Kutzler
>> Das Skript wartet immer noch, gefüttert zu werden - auch wenn mit nur
>> einer E-Mail Adresse, was meiner Meinung nach nicht sinnvoll
>> verhindert werden kann...
>
>
> Es müssen dann immer noch gültige E-Mail-Adressen sein, mit denen
> gefüttert wird.
Wenn ich ne gültige E-Mail Adresse eintrage, dann wird die Mail auch
versendet- auch wenn sie gar nicht existiert. Wie möchtest Du die
Gültigkeit und Echtheit einer E-Mail Adresse denn prüfen?
Stell Dir folgendes vor:
Trage ich als Empfänger eine Mail Adresse ein, von der ich nicht weiss,
ob sie existiert, und versende die Mail, dann antwortet der Mail Server
mit sehr hoher Wahrscheinlichkeit: Adresse gibts nicht und schickt die
Mail zurück. Nun kann ich aber im Kontaktformular aber wiederum eine
andere Adresse als Absender eingeben, die ich auch mit Spam zukleistern
will und die Nachricht, dass es den Adressaten nicht gibt inkl. der Spam
E-Mail wird an die angegebene Absenderadresse geschickt.
Generell sollte man es tunlichst vermeiden, ein derart offene
Kontaktformular bereitzustellen. Die Empfängeradresse sollte, wie von
Dir vorgeschlagen, in einem Skript fest vorgegeben sein. So kann
wenigstens verhindert werden, dass andere Leute zugespammt werden.
>
> Ist wirklich ein spannendes Thema.
>
Man kann stundenlang drüber diskutieren. Eine Lösung dafür zu finden ist
meiner Meinung nach fast unmöglich, wenn man sich mal alle möglichen
Szenarios vorstellt und durchdenkt. Selbst wenn die Wahrscheinlichkeit,
dass eines der Szenarios eintritt, sehr gering ist, kann es trotzdem
sein, dass es jemanden gibt, der genau das ausprobiert und wenn es
funktioniert, setzt es sich durch und alle machen es so.
Ciao,
Tobias
Ulf Dunkel
> Wenn ich ne gültige E-Mail Adresse eintrage, dann wird die Mail auch
> versendet- auch wenn sie gar nicht existiert. Wie möchtest Du die
> Gültigkeit und Echtheit einer E-Mail Adresse denn prüfen?
Dafür gibt's doch fertige Scripte.
> will und die Nachricht, dass es den Adressaten nicht gibt inkl. der Spam
> E-Mail wird an die angegebene Absenderadresse geschickt.
Nö, der entsprechende Server wird befragt, ob er die E-Mail-Adresse mag.
Sagt er "nö", macht mein Script nichts weiter - oder gibt
freundlicherweise ne Meldung aus, daß die angegebene E-Mail-Adresse wohl
nicht gültig ist.
Markus G. Klötzer
> Was sich natürlich mit dem Einsatz einer Armee von Spambots oder einer
> Reihe von offenen Proxies wieder aushebeln lässt.
schon selbst erlebt
cu
mgk
--
Lebenskünstler leben von den Zinsen eines nicht vorhandenen Kapitals.
- Stanislaw Jerzy Lec (1909 - 1966)
Markus G. Klötzer
> Ich mache es in meinen Formularen so, daß es linear nur eine From:- und
> eine To:-Adresse geben kann. Die From:-Adresse wird aus den Angaben des
> Absenders generiert und vor dem weiteren Verarbeiten des Requests an
> deren Server auf Plausibilität geprüft. Sobald da aber Dummfug drinsteht
> (wie z.B. "From:He...@schlingel.de\r\n\Bcc:mhko...@aol.com"), meldet
> mir mein E-Mail-Test, daß diese "eine" E-Mail-Adresse ungültig ist -
> Ende von Lustig.
ack
allerdings gehe ich noch eine Stufe weiter, und gebe die (wie oben
ueberpruefte) emailaddresse in den Reply-To header und nich in den
From, dadurch stelle ich sicher, das ein Kontakt Formular auch
ankommt, wenn der User eine vermurkste Adresse verwendet (vertipper
lommen oft genug vor).
Manche Mailserver schlucken solche ganz einfach.
cu
mgk
s.a Message-ID: <dg48km...@news.mgk.org.uk>
--
NOTICE : Due to financial problems, the light at the end of the tunnel will
be shut down until further notice.
Niels Braczek
> Hi Tobias.
>
>> Wenn ich ne gültige E-Mail Adresse eintrage, dann wird die Mail auch
>> versendet- auch wenn sie gar nicht existiert. Wie möchtest Du die
>> Gültigkeit und Echtheit einer E-Mail Adresse denn prüfen?
>
> Dafür gibt's doch fertige Scripte.
Nein. Alle existierenden Lösungen prüfen nur die Plausibilität. Die
Gültigkeit zu prüfen ist viel zu aufwändig (die RegExp dafür ist AFAIR
fast 10KB groß), die Echtheit kann nur durch Versenden geprüft werden.
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · E-Commerce · Mambo Content Management |
`----------------------------------------------------------------´
Heiko Kuerschner
>> <input type="hidden" name="foo" value="bar">
>
> Und was hindert denjenigen, der das Skript missbrauchen möchte, diesen
> Parameter mittels POST mitzusenden? Dann ist dieser Parameter wieder
> überflüssig!
Mmh, das bringt mich auf eine Idee.
Wie wäre es, wenn man beim Unterschied zwischen Mensch und Bot ansetzt?
In der Verabreitungsgeschwindigkeit.
Als value wird ein timestamp (evtl. eingebettet in einer anderen
zufälligen Zeichenfolge) mit gesendet. Und wenn dann die Zeitspanne
zwischen Aufrufen und Absenden des Formulars kleiner X Sekunden ist,
wird die Mail verworfen und eine Fehlerseite generiert.
Wenn X z.b. um etwa 2 Sekunden liegt, dürfte das keinem weiter auffallen
(man darf natrülich auf der Fehlerseite nicht darauf hinweisen).
--
Kürsche
Wenns 'ner net gwittern tun tut ;)
Linux/*BSD-Anleitungen, Forum und Chat: www.newbie-net.de
HTML per Script validieren: www.unneraans.de/html-validator.sh/
Stephan Ramsauer
> Wie wäre es, wenn man beim Unterschied zwischen Mensch und Bot ansetzt?
> In der Verabreitungsgeschwindigkeit.
> Als value wird ein timestamp (evtl. eingebettet in einer anderen
> zufälligen Zeichenfolge) mit gesendet. Und wenn dann die Zeitspanne
> zwischen Aufrufen und Absenden des Formulars kleiner X Sekunden ist,
> wird die Mail verworfen und eine Fehlerseite generiert.
> Wenn X z.b. um etwa 2 Sekunden liegt, dürfte das keinem weiter auffallen
> (man darf natrülich auf der Fehlerseite nicht darauf hinweisen).
ohne jetzt länger drüber nachgedacht zu haben finde
ich das einen durchaus interessanten Ansatz, den ich
sicherlich im Hinterkopf behalten werde.
Ich selbst kämpfe auch intensiv mit dem Problem.
Einen sonnigen Tag wünscht
Stephan
Richard Körber
> Und was hindert denjenigen, der das Skript missbrauchen möchte, diesen
> Parameter mittels POST mitzusenden? Dann ist dieser Parameter wieder
> überflüssig!
Dieser eine spezielle Missbraucher pappt einfach in ALLE Parameter, die
er findet, eine künstliche E-Mailadresse der eigenen Domain. Nur in
einem Parameter wird die E-Mail selbst mit den Headern gestellt. Mit
jedem Request wandert dieser Teil einmal durch alle verfügbaren Parameter.
Auch bei Hidden-Feldern setzt der Spammer statt dem eigentlichen Inhalt
eine falsche E-Mailadresse. So lässt sich dieser Angriff abwehren.
Die sicherste Methode ist und bleibt erst mal, Captchas einzusetzen,
allerdings auch mit seinen Nachteilen (eine Eingabe mehr, nicht
barrierefrei).
Ulf Dunkel
>>Dafür gibt's doch fertige Scripte.
>
> Nein. Alle existierenden Lösungen prüfen nur die Plausibilität.
Nö, mein Script hier - das nicht von mir ist - fragt den entsprechenden
Server und wertet dessen Antwort aus.
Soll ich's mal posten?
Ulf Dunkel
> dadurch stelle ich sicher, das ein Kontakt Formular auch
> ankommt, wenn der User eine vermurkste Adresse verwendet (vertipper
> lommen oft genug vor).
Dem greife ich ja dadurch vor, daß eine falsche, vertippte oder vom
entsprechenden Server nicht akzeptierte Adresse nicht akzeptiert wird -
der Eingebende wird darauf hingewiesen.
Wenn natürlich jemand seinen Mailserver so konfiguriert hat, daß er
*@foo.bar empfangen kann, aber alles außer myn...@foo.bar automatisch
durch einen SPAM-Filter wegwerfen läßt, hat auch mein Ansatz keine
Chance - weil gegen Doofmannsgehilfen helfen keine Scripte.
Niels Braczek
> Hi Niels.
>
>>>Dafür gibt's doch fertige Scripte.
>>
>> Nein. Alle existierenden Lösungen prüfen nur die Plausibilität.
>
> Nö, mein Script hier - das nicht von mir ist - fragt den entsprechenden
> Server und wertet dessen Antwort aus.
>
> Soll ich's mal posten?
Wenn's nicht zu lang ist... ansonsten bitte PM.
Frank Arthur
> einfach: füge in deinem Formular einfach ein Hidden-Feld mit einem
> beliebigen Text ein, z. B.:
>
> <input type="hidden" name="foo" value="bar">
>
Wie schon von vielen angemerkt, kann man diesen Trick leicht durch das
Lesen des HTML-Codes der Seite erkennen.
Ich sichere meine Formulare (häufig) mit einer Methode ab, mit der ich
auch das doppelte verschicken eines Formulars durch drücken des
Reload-Bottons verhindere.
Dazu verwende ich Sessions. In der Session speichere ich dann eine
zufällige Zahl, die ich auch im "hidden" einsetze. Nur wenn das
Script, das das Formular abarbeitet in der Session und dem Formular
die identische Zahl vorfindet, dann wird fortgefahren.
Also ich sehe keine Möglichkeit das auszutricksen.
Robert Sedlacek
> Dazu verwende ich Sessions. In der Session speichere ich dann eine
> zufällige Zahl, die ich auch im "hidden" einsetze. Nur wenn das
> Script, das das Formular abarbeitet in der Session und dem Formular
> die identische Zahl vorfindet, dann wird fortgefahren.
>
> Also ich sehe keine Möglichkeit das auszutricksen.
Hm, AFAIK kann man in Perl mittels WWW::Mechanize einfach einen UA
simulieren. Den lässt man einfach die Formularfelder ausfüllen, sich die
Cookies etc. merken, und das Formular absenden.
--
thou shallst fear ..
Daniel T. Gorski
>>>Dafür gibt's doch fertige Scripte.
>> Nein. Alle existierenden Lösungen prüfen nur die Plausibilität.
>Nö, mein Script hier - das nicht von mir ist - fragt den entsprechenden
>Server und wertet dessen Antwort aus.
... die bei einem normal konfiguriertem MTA aus sicherheitsgründen
negativ ausfallen wird.
mfg dtg
Daniel T. Gorski
>>> <input type="hidden" name="foo" value="bar">
>> Und was hindert denjenigen, der das Skript missbrauchen möchte, diesen
>> Parameter mittels POST mitzusenden? Dann ist dieser Parameter wieder
>> überflüssig!
>Mmh, das bringt mich auf eine Idee.
>Wie wäre es, wenn man beim Unterschied zwischen Mensch und Bot ansetzt?
>In der Verabreitungsgeschwindigkeit.
>Als value wird ein timestamp (evtl. eingebettet in einer anderen
>zufälligen Zeichenfolge) mit gesendet. Und wenn dann die Zeitspanne
>zwischen Aufrufen und Absenden des Formulars kleiner X Sekunden ist,
>wird die Mail verworfen und eine Fehlerseite generiert.
>Wenn X z.b. um etwa 2 Sekunden liegt, dürfte das keinem weiter auffallen
>(man darf natrülich auf der Fehlerseite nicht darauf hinweisen).
Du kannst davon ausgehen, das z.B. die Bots die ich programmiert habe
damit nicht überlisten kannst. Andere Menschen werden sich die
gleichen Gedanken gemacht haben. Schliesslich soll der Bot keine DoS
Attacke auf einen Server starten und "bewegt" sich deshalb
normallerweise gemächlich.
mfg dtg
Ulf Dunkel
>>Nö, mein Script hier - das nicht von mir ist - fragt den entsprechenden
>>Server und wertet dessen Antwort aus.
>
> ... die bei einem normal konfiguriertem MTA aus sicherheitsgründen
> negativ ausfallen wird.
Was meinst Du damit?
Heiko Kuerschner
> Du kannst davon ausgehen, das z.B. die Bots die ich programmiert habe
> damit nicht überlisten kannst. Andere Menschen werden sich die
> gleichen Gedanken gemacht haben. Schliesslich soll der Bot keine DoS
> Attacke auf einen Server starten und "bewegt" sich deshalb
> normallerweise gemächlich.
Ist ein Argument.
Irmgard Schwenteck
[spam-versuche]
Es ist doch immer der gleiche Müll, der da versucht wird, abzukippen.
Reicht es nicht, die Eingaben zu durchsuchen, nach Text, den ein
normaler Mensch, der wirklich was von einem will, nie hineinschreiben
würde, wie z.B.
" Content-Type: text/plain;"
und dann die Eingabe gleich zu verwerfen?
(Und evtl. der Adresse, die hinter "bcc: " steht, ein 10MB-Mail
zurückzuschicken?)
Gruß
Irmgard