Schutz in Formularen

In Anlehnung an eine von mir angestoßenen Diskussion in d.c.i.w.a.m (1)
zum Thema "Perfekte Forumlare" kamen drei Fragen auf, welche ich hiermit
gerne an euch weiterleiten möchte:

Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

Gibt es Längenbeschränkungen für den Versandt von E-Mails per email()
(Betreff, Absender, Empfänger)?

Welche Möglichkeit der Validierung einer E-Mail-Adresse erscheint euch
am sinnigsten bzw. effektivsten (RegEx, Ping, Explode, MX-Eintrag ect.) ?

mfg,
Ricardo Wickel

(1) Message-ID:
--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Hi Ricardo

Ricardo Wickel wrote:
> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

Jegliche Header, die damit zu tun haben könnten, wohin die Mail geht
(To, Cc, Bcc) fix codieren bzw. keinesfalls über den Client übermitteln.
Sprich keine Mailadressen über GET/POST/Cookies, etc...

> Gibt es Längenbeschränkungen für den Versandt von E-Mails per email()
> (Betreff, Absender, Empfänger)?

Zusammenhang zu oben? Die Funktion email() kenne ich nicht.
Lies RFC 2822.
ftp://sunsite.cnlab-switch.ch/doc/standard/rfc/28xx/2822.txt

> Welche Möglichkeit der Validierung einer E-Mail-Adresse erscheint euch
> am sinnigsten bzw. effektivsten (RegEx, Ping, Explode, MX-Eintrag ect.) ?

RTF: 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
http://www.php-faq.de/q/q-mail-adresse-testen.html

HTH, Johannes

Re: Schutz in Formularen

Johannes Vogel schrieb:
> Hi Ricardo
>
> Ricardo Wickel wrote:
>> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
>> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
>> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?
>
> Jegliche Header, die damit zu tun haben könnten, wohin die Mail geht
> (To, Cc, Bcc) fix codieren bzw. keinesfalls über den Client übermitteln.
> Sprich keine Mailadressen über GET/POST/Cookies, etc...

Diese Frage ist unabhängig von der Unteren, d.h. es geht nicht zwingend
um ein Kontaktformular zum Versenden einer E-Mail, sondern um
"irgendein" Formular (Login, Umfrage ect.)

>> Gibt es Längenbeschränkungen für den Versandt von E-Mails per email()
>> (Betreff, Absender, Empfänger)?
>
> Zusammenhang zu oben? Die Funktion email() kenne ich nicht.
> Lies RFC 2822.
> ftp://sunsite.cnlab-switch.ch/doc/standard/rfc/28xx/2822.txt

Sorry, verschrieben. Natürlich meinte ich mail()

>> Welche Möglichkeit der Validierung einer E-Mail-Adresse erscheint euch
>> am sinnigsten bzw. effektivsten (RegEx, Ping, Explode, MX-Eintrag ect.) ?
>
> RTF: 15.9. Wie kann ich die Gültigkeit einer Mailadresse testen?
> http://www.php-faq.de/q/q-mail-adresse-testen.html

Schon klar, aber ist das auch das "Null Plus Ultra"?

mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Ricardo Wickel schrieb:

> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formulare=
n=20
> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP=20
> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

Du meinst Kontaktformulare? Bayesian- und Markov-Filter.
Benutzer-Registrierung.

Fur ein Forum habe ich eine kleine Funktion geschrieben, die den Betreff
und die Mitteilung auf Stop-Wörter prüft und bei Vorhandensein dieser=

Wörter (meist Medikamentenbezeichnungen) einfach keinen Datenbankeintra=
g
vornimmt. Eine "Die, bot, die" Message bringt ja nicht wirklich etwas.

> Gibt es Längenbeschränkungen für den Versandt von E-Mails per ema=
il()=20
> (Betreff, Absender, Empfänger)?

Ja. Steht alles im STD11 (RfC822).

> Welche Möglichkeit der Validierung einer E-Mail-Adresse erscheint euc=
h=20
> am sinnigsten bzw. effektivsten (RegEx, Ping, Explode, MX-Eintrag ect.)=
?

Ideal ist das Double-Opt-In bei Registrierung. Ansonsten gibt es keine
sinnvolle Möglichkeit E-Mail-Adressen zu validieren. Ich beschränke m=
ich
auf den simplen Test auf Vorhandensein des '@' im Stringinneren.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Schutz in Formularen

Hallo

Niels Braczek schrieb:

> Fur ein Forum habe ich eine kleine Funktion geschrieben, die den Betreff
> und die Mitteilung auf Stop-Wörter prüft und bei Vorhandensein dieser
> Wörter (meist Medikamentenbezeichnungen) einfach keinen Datenbankeintrag
> vornimmt. Eine "Die, bot, die" Message bringt ja nicht wirklich etwas.

Hilft es eigentlich, in solchen Fällen in ein furchtbar langsames script
zu verzweigen? Blockiert man dann den bot für ne Weile oder was passiert
dann?
Was geschieht bei header("Location:...")?

Gruß
Irmgard

Re: Schutz in Formularen

Irmgard Schwenteck schrieb:

> Hilft es eigentlich, in solchen Fällen in ein furchtbar langsames script
> zu verzweigen?

Ein langsames Script? Du meinst hier sowas wie sleep(??) einbauen?
Das könntest DU ja erst in dem Moment, wenn Du bereits erkannt hast das
das Gegenüber z.B. ein Bot ist. Da wirds wohl am einfachsten und
sinnvollsten sein zu sagen "Hier ist Zick für Dich" + Scriptende

Oder welchen Grund kannst Du Dir vorstellen der ein solches von Dir
ersonnenes Verhalten rechtfertigt.

> Blockiert man dann den bot für ne Weile oder was passiert
> dann?

Das kommt darauf an ob der Bot die Konfiguration von Timeouts zuläst
oder anderweitige Laufzeit-einschränkungen ermöglicht. Das wissen wohl
bloss die, die Bots bauen

> Was geschieht bei header("Location:...")?

Eine Umleitung. :-) Ob Bots der folgen wollen/sollen hängt wohl in
erster Linie von Bot, dessen Features und dessen Betreiber ab.

Eins ist auf jeden Fall Sicher. Auch Bots werden immmer ausgereifter.

Evtl. gibts ja ne geeignetere Stelle um sich über Bots zu informieren.
astalavista.box.sk + genug Suchenergie zeigt evtl. bereits was auf.

MfG, Ulf

Re: Schutz in Formularen

Niels Braczek schrieb:

> Fur ein Forum habe ich eine kleine Funktion geschrieben, die den Betreff
> und die Mitteilung auf Stop-Wörter prüft und bei Vorhandensein dieser
> Wörter (meist Medikamentenbezeichnungen) einfach keinen Datenbankeintrag
> vornimmt.

Bei mir verhindern folgende strstr-Tests Spam über Kontaktformulare
recht zuverlässig:

> $checks = array(
> "\nContent-Type:" => "enthält einen Content-Type-Header",
> "\nContent-Transfer-Encoding:" => "enthält einen Content-Transfer-Encoding-Header",
> "\nSubject:" => "enthält einen Subject-Header",
> "\nTo:" => "enthält einen To-Header",
> "\nCC:" => "enthält einen CC-Header",
> "\nBCC:" => "enthält einen BCC-Header",
> "\nFrom:" => "enthält einen From-Header",
> "This is a multi-part message in MIME format" => "enthält eine MIME-Nachricht",
> " > "" => "enthält einen schließenden HTML a-Tag",
> "[url=" => "enthält einen öffnenden BB-Code URL-Tag",
> "[/url]" => "enthält einen schließenden BB-COde URL-Tag"
> );

Da es unwahrscheinlich aber möglich ist, dass einer der Strings auch von
einem normalen Benutzer eingegeben wird, gebe ich eine entsprechende
Meldung aus, die auf den "Fehler" hinweist.


Grüße, Matthias


--
http://www.trullala.de
--
Der Trend geht ganz eindeutig zur Zweitsignatur.

Re: Schutz in Formularen

Ricardo Wickel schrieb:
> In Anlehnung an eine von mir angestoßenen Diskussion in d.c.i.w.a.m (1)
> zum Thema "Perfekte Forumlare" kamen drei Fragen auf, welche ich hiermit
> gerne an euch weiterleiten möchte:
>
> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

Ich habe nun einmal eine Liste der mir bekannten Möglichkeiten erstellt.
Anmerkung: Es soll sich hierbei nur um solche Möglichkeiten handeln,
welche den Benutzer in keinster Weise einschränken bzw. ihm die Arbeit
erschweren (z.B. Java-Script, Cookies, Captchas, Rechenaufgaben ect.)

1.Formular-Elemente-Überprüfung
Überprüfung ob alle Formular-Elemente vorhanden sind.

2.Referrer-Überprüfung
Überprüfung ob der Referrer mit der URL des Original-Formulars
übereinstimmt.

3.Formular-Daten reinigen
Tags entfernen, Umlaute/ Sonderzeichen umformen, überflüssige Zeichen
entfernen, Backslashes entfernen.
Gegebenenfalls für Datenbank-Eintragung vorbereiten.

4.Session-Daten setzen
In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
existiert gar nicht, wird der Prozess abgebrochen.

5.POST
Weil POST-Bots schwieriger sind zu programmieren als GET.
D.h. auch register_globals= Off

6.Bei E-Mail-Versandt content-type:|bcc:|cc:|to:|from: rausfiltern/ löschen

7.Timestamps/ Hash-Werte
http://www.drweb.de/webmaster/sichere-formulare-teil4.shtml

Was haltet ihr von alledem bzw. fällt euch noch etwas ein?

mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Irmgard Schwenteck schrieb:
> Niels Braczek schrieb:
>=20
>> Fur ein Forum habe ich eine kleine Funktion geschrieben, die den Betre=
ff
>> und die Mitteilung auf Stop-Wörter prüft und bei Vorhandensein die=
ser
>> Wörter (meist Medikamentenbezeichnungen) einfach keinen Datenbankein=
trag
>> vornimmt. Eine "Die, bot, die" Message bringt ja nicht wirklich etwas.=

>=20
> Hilft es eigentlich, in solchen Fällen in ein furchtbar langsames scr=
ipt=20
> zu verzweigen? Blockiert man dann den bot für ne Weile oder was passi=
ert=20
> dann?

Das hängt von der konkreten Implementierung des Bots ab. Im
Zweifelsfalle interessiert das den Bot also herzlich wenig. Ich hatte
mal die Idee, die Link-Adresse aus der Spam-Mitteilung mit einem
DoS-Angriff zu versehen...

> Was geschieht bei header("Location:...")?

Dasselbe wie oben. Der Bot kann der Weiterleitung folgen, muss es aber
nicht.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Schutz in Formularen

Ricardo Wickel schrieb:

>> In Anlehnung an eine von mir angestoßenen Diskussion in d.c.i.w.a.m
>> (1) zum Thema "Perfekte Forumlare" kamen drei Fragen auf, welche ich
>> hiermit gerne an euch weiterleiten möchte:
>>
>> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
>> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
>> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?
>
> Ich habe nun einmal eine Liste der mir bekannten Möglichkeiten erstellt.
> Anmerkung: Es soll sich hierbei nur um solche Möglichkeiten handeln,
> welche den Benutzer in keinster Weise einschränken bzw. ihm die Arbeit
> erschweren (z.B. Java-Script, Cookies, Captchas, Rechenaufgaben ect.)
>
> 1.Formular-Elemente-Überprüfung
> Überprüfung ob alle Formular-Elemente vorhanden sind.
>
> 2.Referrer-Überprüfung
> Überprüfung ob der Referrer mit der URL des Original-Formulars
> übereinstimmt.

Nicht sinnvoll, da dieses Feld optional ist und auch häufig bei
lebendigen Anwendern nicht gesetzt ist.

> 3.Formular-Daten reinigen
> Tags entfernen, Umlaute/ Sonderzeichen umformen, überflüssige Zeichen
> entfernen, Backslashes entfernen.
> Gegebenenfalls für Datenbank-Eintragung vorbereiten.

Das ist ganz falsch. Da du wert auf Sicherheit legst, benötigst du ein
restriktives Sicherheitssystem. Dieses besagt, dass wenn du eine
fehlerhafte Eingabe feststellst, diese Eingabe nicht weiter
verarbeitest. Denn du kannst niemals sicherstellen, dass du wirklich
alle Fehler beseitigst.

> 4.Session-Daten setzen
> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
> existiert gar nicht, wird der Prozess abgebrochen.

Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
oder Session-Fixation oder Session-Riding machen.

> 5.POST
> Weil POST-Bots schwieriger sind zu programmieren als GET.
> D.h. auch register_globals= Off

Das stimmt nicht. Post und Get unterscheiden sich in der Implementation
minimal. register_globals=off ist aber immer eine gute Idee.

Gruß,
Torsten

Re: Schutz in Formularen

Ricardo Wickel schrieb:

> 5.POST
> Weil POST-Bots schwieriger sind zu programmieren als GET.

Das ist nicht richtig. Es gibt fertige Klassen wie Snoopy, die
POST-Zugriffe zum Kinderspiel machen.

> Was haltet ihr von alledem bzw. fällt euch noch etwas ein?

Joomla fügt dem Formular ein hidden-Input mit wechselndem Namen hinzu,
das beim Auswerten gecheckt wird. Ist dieses Feld nicht vorhanden, wird
die Verarbeitung abgebrochen.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Schutz in Formularen

Torsten Zuehlsdorff schrieb:
> Ricardo Wickel schrieb:
>
>> 4.Session-Daten setzen
>> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
>> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
>> existiert gar nicht, wird der Prozess abgebrochen.
>
> Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
> der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
> oder Session-Fixation oder Session-Riding machen.

Ohne Cookie, sondern mit einem Hidden-Feld, was soweit ich weiß geht.

So wie ich das verstehe, ist es trotzdem nicht möglich die Bedingung zu
erfüllen? Denn der Inhalt der Variable ist nur auf dem Server zu sehen
und wird mithilfe der Session ID serverseitig verarbeitet. D.h. das die
Session ID nichts bringt.
Der Bot müsste das Formular aufrufen, die gültige Session ID auslesen
und dann beim Senden der Daten diese mitgeben.

Keine Lösung des Sicherheitsproblems, aber dennoch ein Hinderniss.


mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Niels Braczek schrieb:
> Ricardo Wickel schrieb:
>
>> Was haltet ihr von alledem bzw. fällt euch noch etwas ein?
>
> Joomla fügt dem Formular ein hidden-Input mit wechselndem Namen hinzu,
> das beim Auswerten gecheckt wird. Ist dieses Feld nicht vorhanden, wird
> die Verarbeitung abgebrochen.

Der Bot ließt das Feld aus und übergibt es einfach. Da ist die
Session-Variante schon sinnvoller, da dort der Aufwand noch bisschen
größer ist für einen Bot-Programmierer.

mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Ricardo Wickel schrieb:
> Niels Braczek schrieb:

>> Joomla fügt dem Formular ein hidden-Input mit wechselndem Namen hinz=
u,
>> das beim Auswerten gecheckt wird. Ist dieses Feld nicht vorhanden, wir=
d
>> die Verarbeitung abgebrochen.
>=20
> Der Bot ließt das Feld aus und übergibt es einfach. Da ist die=20
> Session-Variante schon sinnvoller, da dort der Aufwand noch bisschen=20
> größer ist für einen Bot-Programmierer.

Es gibt in Bezug auf den Aufwand keinen Unterschied zur Session. Die
Session-ID könnte der Bot genauso auslesen und weitergeben. Zumal es fü=
r
Bots überhaupt kein Problem ist auch Cookies zu unterstützen. Die
Joomla-Lösung tut dasselbe, ohne dafür allerdings eine Session zu
benötigen.

MfG
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Schutz in Formularen

Ricardo Wickel schrieb:

>>> 4.Session-Daten setzen
>>> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
>>> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
>>> existiert gar nicht, wird der Prozess abgebrochen.
>>
>> Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
>> der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
>> oder Session-Fixation oder Session-Riding machen.
>
> Ohne Cookie, sondern mit einem Hidden-Feld, was soweit ich weiß geht.

Schau in die Doku und glaube mir: Standard ist der Cookie. Falls dies
nicht möglich ist, gibt es die Option, es an die URL anzuhängen.

> So wie ich das verstehe, ist es trotzdem nicht möglich die Bedingung zu
> erfüllen? Denn der Inhalt der Variable ist nur auf dem Server zu sehen
> und wird mithilfe der Session ID serverseitig verarbeitet. D.h. das die
> Session ID nichts bringt.
> Der Bot müsste das Formular aufrufen, die gültige Session ID auslesen
> und dann beim Senden der Daten diese mitgeben.
>
> Keine Lösung des Sicherheitsproblems, aber dennoch ein Hinderniss.

Ja und Nein. Ein Hindernis: Nein. Eine Besserung: Ja.
Denn du kannst in der Session Werte setzen, die der Bot niemals sehen
kann. Desweiteren kannst du diese mit zufällig gesetzen Werten aus dem
Formular vergleichen. Wenn ein Fehler auftritt: Session löschen und der
Bot hat keine Session mehr.

Gruß,
Torsten

Re: Schutz in Formularen

Torsten Zuehlsdorff schrieb:
> Ricardo Wickel schrieb:
>
>>>> 4.Session-Daten setzen
>>>> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
>>>> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
>>>> existiert gar nicht, wird der Prozess abgebrochen.
>>> Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
>>> der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
>>> oder Session-Fixation oder Session-Riding machen.
>> Ohne Cookie, sondern mit einem Hidden-Feld, was soweit ich weiß geht.
>
> Schau in die Doku und glaube mir: Standard ist der Cookie. Falls dies
> nicht möglich ist, gibt es die Option, es an die URL anzuhängen.

Standart schon, aber bei einem Formular eher unschön.
http://tut.php-q.net/sessions.html

mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Torsten Zuehlsdorff schrieb:
> Ricardo Wickel schrieb:
>
>>>> 4.Session-Daten setzen
>>>> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
>>>> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
>>>> existiert gar nicht, wird der Prozess abgebrochen.
>>> Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
>>> der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
>>> oder Session-Fixation oder Session-Riding machen.
>> Ohne Cookie, sondern mit einem Hidden-Feld, was soweit ich weiß geht.
>
> Schau in die Doku und glaube mir: Standard ist der Cookie. Falls dies
> nicht möglich ist, gibt es die Option, es an die URL anzuhängen.
>
>> So wie ich das verstehe, ist es trotzdem nicht möglich die Bedingung zu
>> erfüllen? Denn der Inhalt der Variable ist nur auf dem Server zu sehen
>> und wird mithilfe der Session ID serverseitig verarbeitet. D.h. das die
>> Session ID nichts bringt.
>> Der Bot müsste das Formular aufrufen, die gültige Session ID auslesen
>> und dann beim Senden der Daten diese mitgeben.
>>
>> Keine Lösung des Sicherheitsproblems, aber dennoch ein Hinderniss.
>
> Ja und Nein. Ein Hindernis: Nein. Eine Besserung: Ja.
> Denn du kannst in der Session Werte setzen, die der Bot niemals sehen
> kann. Desweiteren kannst du diese mit zufällig gesetzen Werten aus dem
> Formular vergleichen. Wenn ein Fehler auftritt: Session löschen und der
> Bot hat keine Session mehr.

Dann ließt der Bot eben die zufällig gesetzten Werte aus ;-)

mfg,
Ricardo Wickel

--
http://doppeltgedacht.de/ | Weblog
http://wiky.de/ | Privat
http://ql-webdesign.de/ | Webdesign/ Programmierung

Re: Schutz in Formularen

Hallo

Ulf Kadner schrieb:
>
> Ein langsames Script? Du meinst hier sowas wie sleep(??) einbauen?
> Das könntest DU ja erst in dem Moment, wenn Du bereits erkannt hast das
> das Gegenüber z.B. ein Bot ist. Da wirds wohl am einfachsten und
> sinnvollsten sein zu sagen "Hier ist Zick für Dich" + Scriptende

Nach Sichtung der logfiles werd ich einfach die IP 81.95.146.162 blocken.

> Oder welchen Grund kannst Du Dir vorstellen der ein solches von Dir
> ersonnenes Verhalten rechtfertigt.

War nur so eine Idee, den bot wenigstens ein wenig aufzuhalten, bevor er
weiterspammt.
Ich komm aus dem Urlaub wieder und das Gästebuch des Kunden ist mit 700
Einträgen vollgemüllt.
Und er wollte absolut nicht, daß die Einträge erst freigeschaltet werden
müssen, sondern daß sie generell reinkommen und dann ggf. gelöscht
werden. Die 700 Benachrichtigungsmails über einen neuen Gästebucheintrag
hat er wohl nicht gelesen ... ;)


>> Was geschieht bei header("Location:...")?
>
> Eine Umleitung. :-) Ob Bots der folgen wollen/sollen hängt wohl in
> erster Linie von Bot, dessen Features und dessen Betreiber ab.

Tut er nicht, hab mal die logfiles daraufhin untersucht.
Davon werden nur die paar manuellen Spammer getroffen.

> Eins ist auf jeden Fall Sicher. Auch Bots werden immmer ausgereifter.

Leider.

Gruß
Irmgard

Re: Schutz in Formularen

Hallo,

Ricardo Wickel schrieb:
> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

ich gehöre eher zu den Nichfachleuten, zumindest relativ zu den
meisten Lesern hier ;-)

Ich verwende gegen Spam die von Matthias bevorzugte Methode, das
funktioniert recht gut.
Ansonsten liegt das eigentliche Script in einem per .htacces
geschütztem Verzeichnis.
Dies lässt sich vom Webserver her hervorragend includen, Bots haben
aber keine Chance.

cu,
Nobbi

Re: Schutz in Formularen

Ricardo Wickel wrote:

> Welche Schutzmaßnahmen zur Verhinderung des Missbrauchs von Formularen
> für Spam-Zwecke, Hackattacken ect. würdet ihr auf Basis von PHP
> empfehlen bzw. welche existieren und hindern den Benutzer *nicht*?

Du fragst viel zu allgemein. PHP bietet verschiedene Methoden um
Formulareingaben zu verarbeiten. Mach Dir am besten selbst ein Bild. Hier
findest Du die Stringfunktionen:




> Gibt es Längenbeschränkungen für den Versandt von E-Mails per email()
> (Betreff, Absender, Empfänger)?

1000 Zeichen pro Zeile (incl. CRLF)

> Welche Möglichkeit der Validierung einer E-Mail-Adresse erscheint euch
> am sinnigsten bzw. effektivsten (RegEx, Ping, Explode, MX-Eintrag ect.) ?

Das kommt darauf an. Wenn du das Validieren RFC2822-konform machen willst,
dann überprüfst du eigentlich nur die Syntax. Wenn Du aber sicherstellen
willst, daß die Emailadresse wirklich zugeordnet ist, dann hast Du das
Problem, daß Du lediglich den Teil rechts vom @ prüfen kannst.

Beispiel: ich@host wäre eine RFC2822-konforme Emailadresse. Allerdings hat
die keine Top-Level-Domain. ich@host.d ist ebenfalls RFC2822 konform.
Allerdings ist d keine gültige Top-Level-Domain (z.B. de,dk).

Was am sinnigsten ist, mußt Du selber entscheiden. Ich würde
nicht-vertrauenswürdigen Benutzern keinen Mailversand gestatten.

Gruß,

Oliver

Re: Schutz in Formularen

[Irmgard Schwenteck in de.comp.lang.php.misc]

> Eine "Die, bot, die" Message bringt ja nicht wirklich etwas.

> Hilft es eigentlich, in solchen Fällen in ein furchtbar langsames script
> zu verzweigen? Blockiert man dann den bot für ne Weile oder was passiert
> dann?

In diesem Zusammengang fällt mir "Teergrubing" (sic) ein:



Eine Suche nach "Teergrube" oder "Teergrubing" mittels einer Suchmaschiner
deiner Wahl ist sicher hilfreich um sich in die pros und cons einzulesen.

mfg dtg

Re: Schutz in Formularen

Ricardo Wickel schrieb:

>>>>> 4.Session-Daten setzen
>>>>> In der Formular-Datei wird zu Anfang eine Session-Variable gesetzt.
>>>>> Stimmt diese nach dem Absenden nicht mit der Originalen überein oder
>>>>> existiert gar nicht, wird der Prozess abgebrochen.
>>>>
>>>> Das ist gut, benötigt allerdings einen Cookie. Anderfalls steht es in
>>>> der URL. Hierbei solltest du dir Gedanken zum Thema Session-Hijacking
>>>> oder Session-Fixation oder Session-Riding machen.
>>>
>>> Ohne Cookie, sondern mit einem Hidden-Feld, was soweit ich weiß geht.
>>
>> Schau in die Doku und glaube mir: Standard ist der Cookie. Falls dies
>> nicht möglich ist, gibt es die Option, es an die URL anzuhängen.
>
> Standart schon, aber bei einem Formular eher unschön.
> http://tut.php-q.net/sessions.html

Was jetzt wie meiner Aussage widerspricht? ;)

Gruß,
Torsten

Re: Schutz in Formularen

Ricardo Wickel schrieb:
> Standart schon, aber bei einem Formular eher unschön.

StandarT tut schon irgendwie in den Augen weh...
....aber wenn das so weiter geht steht das auch bald im Duden

Standart (ehem. Standard)
......................


gruß, Frank

Re: Schutz in Formularen

Frank Schenk schrieb:
> Ricardo Wickel schrieb:

>> Standart schon, aber bei einem Formular eher unschön.
>=20
> StandarT tut schon irgendwie in den Augen weh...
> ...aber wenn das so weiter geht steht das auch bald im Duden
>=20
> Standart (ehem. Standard)
> .....................

Ich dachte immer, "Standart" sei Neudeutsch für "State of the Art"...

SCNR
Niels

--=20
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Re: Schutz in Formularen

Niels Braczek schrieb:
> Frank Schenk schrieb:
>> Ricardo Wickel schrieb:
>
>>> Standart schon, aber bei einem Formular eher unschön.
>> StandarT tut schon irgendwie in den Augen weh...
>> ...aber wenn das so weiter geht steht das auch bald im Duden
>>
>> Standart (ehem. Standard)
>> .....................
>
> Ich dachte immer, "Standart" sei Neudeutsch für "State of the Art"...

Nein, eigentlich heißt das Stehkunst aber da alles anglizismiert werden
muss eben Standart!

Guckst du hier: http://de.wikipedia.org/Standart

:-)

Da das aber nun sehr recovery ist ab damit nach darw


gruß´, Frank