Hallo,

bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
einfaches Script unzählige Datenbankeinträge zu erzeugen
(Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
schützt Ihr Eure Webseiten dagegen?

schöne grüße, steffen

steffen horst schrieb:
> Hallo,
>
> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
> einfaches Script unzählige Datenbankeinträge zu erzeugen
> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
> schützt Ihr Eure Webseiten dagegen?
>
> schöne grüße, steffen

Vllt kannst du dich etwas Konkreter ausdrücken. Geht es dir jetzt um
Sicherheit/Sicherheitslücken oder eher um Autorisierung/Authentifizerung
von Benutzern.

MfG Benny

steffen horst wrote:

> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
> einfaches Script unzählige Datenbankeinträge zu erzeugen

Wenn man dieses Scipt so schreibt. Klar warum nicht...

> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
> schützt Ihr Eure Webseiten dagegen?

Gegen was denn? Gegen das Script das was in der DB macht? Lösch es einfach..

Eigentlich solltest Du es wissen wie man fragt. Aber aus Deiner Frage
wird wahrscheinlich keiner schlau. Daher:

1.17. Wie stelle ich meine Frage an die Newsgroup am sinnvollsten?
http://www.php-faq.de/q/q-newsgroup-fragen.html

Ich kann mal raten was Du evtl. meinen könntest:

Meinst Du damit eigene Scripte die so schlecht programmiert sind das man
von Außen unerlaubte Aktionen ausführen kann?

12.11. Prüfe importierte Parameter. Traue niemandem
http://www.php-faq.de/q/q-sicherheit-parameter.html

16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
http://www.php-faq.de/q/q-sql-injection.html

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

* steffen horst wrote:

> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
> einfaches Script unzählige Datenbankeinträge zu erzeugen
> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
> schützt Ihr Eure Webseiten dagegen?

Ein (begrenzter) Schutz ist:
http://de.wikipedia.org/wiki/Captcha

G.

--
BM Computer-Services, Bergmannstr. 66, 10961 Berlin
Webdesign, Internet, Layout und Grafik
Tel.: 030/20649400, mobil 0175/7419517, Fax: 030/20649401
Web: http://www.bmservices.de, eMail: kontakt [at] bmservices.de

Hi!

steffen horst schrieb:
> Hallo,
>
> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. e=
in
> einfaches Script unzählige Datenbankeinträge zu erzeugen
> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
> schützt Ihr Eure Webseiten dagegen?

Wirf mal einen Blick hierauf:
http://de.wikipedia.org/wiki/Captcha

Captchas können Dir helfen, dass Deine Formulare nur von Menschen
bedient werden, in dem Du es einfachen Skripten unmöglich, und guten
Skripten extrem schwierig gestaltest Sie zu benutzen/abzusenden.

Natürlich können Menschen auch Murks verzapfen, falls Du damit auch n=
och
ein Problem hast, wirst Du um Authentifizierung, also einen
geschlossenen Benutzerkreis, nicht herum kommen.

Im Hinterkopf sollte man immer behalten, dass ein Captcha die
barrierefreiheit Deiner Seite beeinträchtigen kann...

Grüße,

Nico

Hallo, Gerome,

Du (kontakt) meintest am 26.11.07:

> * steffen horst wrote:

>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B.
>> ein einfaches Script unzählige Datenbankeinträge zu erzeugen
>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>> schützt Ihr Eure Webseiten dagegen?

> Ein (begrenzter) Schutz ist:
> http://de.wikipedia.org/wiki/Captcha

http://www.heise.de/newsticker/meldung/98097/

Viele Gruesse!
Helmut

Nicolai Scheer wrote:

> Captchas können Dir helfen, dass Deine Formulare nur von Menschen
> bedient werden

Bitte entschuldige, aber das ist absolut falsch.
Captchas sperren genauso Menschen aus wie Maschinen. Usability ist hier
das Stichwort. Es existiert ja auch gar keine Notwendigkeit sowas ins
Formular einzubauen. Zahlreiche Techniken, die hier alle schon in der NG
diskutiert worden bieten die Möglichkeit eines transparenten Schutzes
der vom User keinerlei Extra-Eingaben erwartet und Behinderte nicht als
Maschinen behandelt.

Es gibt keine funktionierende Möglichkeit zu ermitteln ob ein Mensch
oder eine Maschine das Formular bedient!

> Im Hinterkopf sollte man immer behalten, dass ein Captcha die
> barrierefreiheit Deiner Seite beeinträchtigen kann...

Es kann nicht nur, es *tut*!


--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

Ulf Kadner schrieb:
> Nicolai Scheer wrote:
>
>> Captchas können Dir helfen, dass Deine Formulare nur von Menschen
>> bedient werden
>
> Bitte entschuldige, aber das ist absolut falsch.
> Captchas sperren genauso Menschen aus wie Maschinen.

Ja. Und natürlich gibt es auch genügend Maschinen, die ein Catpcha
verstehen.

Gruß,
Torsten

Hi!

Ulf Kadner schrieb:
> Nicolai Scheer wrote:
>
>> Captchas können Dir helfen, dass Deine Formulare nur von Menschen
>> bedient werden
>
> Bitte entschuldige, aber das ist absolut falsch.
> Captchas sperren genauso Menschen aus wie Maschinen. Usability ist hier=

> das Stichwort.

Du hast ja recht. Es ist ja aber nicht so, als hätte ich dieses Thema
unerwähnt gelassen. Kam vielleicht nicht so gut rüber...

> Es existiert ja auch gar keine Notwendigkeit sowas ins
> Formular einzubauen. Zahlreiche Techniken, die hier alle schon in der N=
G
> diskutiert worden bieten die Möglichkeit eines transparenten Schutzes=

> der vom User keinerlei Extra-Eingaben erwartet und Behinderte nicht als=

> Maschinen behandelt.

Dann wäre ich (und der OP bestimmt auch) Dir um ein paar Stichpunkte an=

dieser Stelle dankbar!
Ich lese schon des =D6fteren hier herein, aber da bin ich wohl nicht so
gut informiert wie ich dachte.
In welche Richtung geht denn ein "transparenter Schutz" ohne
"Extra-Eingaben"?

Grüße,

Nico

benjamin radtke wrote:
>steffen horst schrieb:
>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
>> einfaches Script unzählige Datenbankeinträge zu erzeugen
>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>> schützt Ihr Eure Webseiten dagegen?
>Vllt kannst du dich etwas Konkreter ausdrücken. Geht es dir jetzt um
>Sicherheit/Sicherheitslücken oder eher um Autorisierung/Authentifizerung
>von Benutzern.

Nein, ich meine ein einfaches Script, wie es in PHP z.B. so aussehen
könnte:

<?php

for ($i=0; $i < $whatever; $i++)
{

fopen("http://example.com/register.php?name=a$i&mail=a$i [at] exa mple.com",'r');
}

?>

Dieses würde über die imaginäre Benutzerkonto-Anmeldungsseite
register.php $whatever neue Benutzeraccounts anlegen. Die Frage ist:
wie schützt Ihr Eure Webseiten gegen solche Massenzugriffe?

Schöne Grüße, Steffen

Ulf Kadner wrote:
>steffen horst wrote:
>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
>> einfaches Script unzählige Datenbankeinträge zu erzeugen
>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>> schützt Ihr Eure Webseiten dagegen?
>Gegen was denn? Gegen das Script das was in der DB macht? Lösch es einfach..

Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
PHP-Scripte, welche nach einer bestimmten Benutzereingabe
(üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
eMails versendet?

Eine Möglichkeit wäre, Captchas einzubauen. Diese werden jedoch auch
(sinnvollerweise) von der Mehrheit abgelehnt.

Also - welche weiteren Schutzmechanismen gibt es?

>12.11. Prüfe importierte Parameter. Traue niemandem
>http://www.php-faq.de/q/q-sicherheit-parameter.html
>
>16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
>http://www.php-faq.de/q/q-sql-injection.html

Weder noch - ich meine massenhaftes Absenden 'guter' (oder besser
gesagt 'unböser' Parameter an ein Script.

Schöne Grüße, Steffen

steffen horst schrieb:
> Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
> anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
> maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
> PHP-Scripte, welche nach einer bestimmten Benutzereingabe
> (üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
> Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
> dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
> eMails versendet?

Vielleicht eine Wartezeit einbauen, sodass ein Benutzer das selbe Skript
nur alle 5 Minuten aufrufen darf. So würdest die Zeiträume und die Last
etwas vermindern. Würde ein Benutzer dann durch starke "Aktivität"
auffallen, könnte man Ihn ja sperren. Beides ist jedoch erst effektiv,
wenn eine Authentifizierung vorangeschaltet wird.

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Hallo!

"steffen horst" <moin666 [at] email.com> schrieb im Newsbeitrag
news:q4dlk3tq2jc7sqps54n24j32rnelsc0ekm [at] 4ax.com...
> Hallo,
>
> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
> einfaches Script unzählige Datenbankeinträge zu erzeugen
> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
> schützt Ihr Eure Webseiten dagegen?

Nu rmal so aus dem Bauch:
in der index.php folgendes rein:
define("INTERN", 1);

in der Datei, wo etwas gemacht werden soll und es muss über die Hauptseite
kommen:
if (defined("INTERN"))
{
// Senden, etc

}
else
{
// Fehler ausgeben, oder tot stellen, oder so.
}


Olaf

Christoph Herrmann wrote:
>steffen horst schrieb:
>
>> Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
>> anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
>> maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
>> PHP-Scripte, welche nach einer bestimmten Benutzereingabe
>> (üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
>> Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
>> dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
>> eMails versendet?
>Vielleicht eine Wartezeit einbauen, sodass ein Benutzer das selbe Skript
>nur alle 5 Minuten aufrufen darf. So würdest die Zeiträume und die Last
>etwas vermindern. Würde ein Benutzer dann durch starke "Aktivität"
>auffallen, könnte man Ihn ja sperren. Beides ist jedoch erst effektiv,
>wenn eine Authentifizierung vorangeschaltet wird.

Dies ist, wie Du richtig schreibst, nur nach Authentifizierung
sinnvoll umzusetzen und klappt deshalb für die beiden Beispiele
(Gästebucheinträge und Benutzeranmeldungen) nicht.

Schöne Grüße, Steffen

steffen horst schrieb:
> Ulf Kadner wrote:
>> steffen horst wrote:
>>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
>>> einfaches Script unzählige Datenbankeinträge zu erzeugen
>>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>>> schützt Ihr Eure Webseiten dagegen?
>> Gegen was denn? Gegen das Script das was in der DB macht? Lösch es einfach..
>
> Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
> anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
> maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
> PHP-Scripte, welche nach einer bestimmten Benutzereingabe
> (üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
> Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
> dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
> eMails versendet?
>
> Eine Möglichkeit wäre, Captchas einzubauen. Diese werden jedoch auch
> (sinnvollerweise) von der Mehrheit abgelehnt.
>
> Also - welche weiteren Schutzmechanismen gibt es?

Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.

Gruß,
Torsten

Torsten Zühlsdorff wrote:
>steffen horst schrieb:
>> Ulf Kadner wrote:
>>> steffen horst wrote:
>>>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
>>>> einfaches Script unzählige Datenbankeinträge zu erzeugen
>>>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>>>> schützt Ihr Eure Webseiten dagegen?
>>> Gegen was denn? Gegen das Script das was in der DB macht? Lösch es einfach..
>> Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
>> anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
>> maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
>> PHP-Scripte, welche nach einer bestimmten Benutzereingabe
>> (üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
>> Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
>> dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
>> eMails versendet?
>>
>> Eine Möglichkeit wäre, Captchas einzubauen. Diese werden jedoch auch
>> (sinnvollerweise) von der Mehrheit abgelehnt.
>>
>> Also - welche weiteren Schutzmechanismen gibt es?
>
>Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
>existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.

Wär mir neu, dass nicht bei jedem Aufruf von

fopen("http://example.com/register.php?name=a$i&mail=a$i [at] exa mple.com",'r');

ein neues Formular erstellt wird. :)

Schöne Grüße, Steffen

(Helmut Hullen) wrote:
>Hallo, Gerome,
>> * steffen horst wrote:
>>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B.
>>> ein einfaches Script unzählige Datenbankeinträge zu erzeugen
>>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>>> schützt Ihr Eure Webseiten dagegen?
>
>> Ein (begrenzter) Schutz ist:
>> http://de.wikipedia.org/wiki/Captcha
>
> http://www.heise.de/newsticker/meldung/98097/


Sehr schön!

Ebensolche Grüße, Steffen

steffen horst wrote:

Hallo,

> Womit verhindert Ihr einen maschinellen Massenzugriff auf Eure Script=
e?

- POST wirklich POST und nicht GET Daten und umgekehrt. Also,
nicht $_REQUEST benutzen.
- Allgemeine Prüfung darauf, ob die gesendeten Daten das
enthalten, was sie enthalten dürfen. Ist die URL eine URL, die
E-Mail eine E-Mail ( [at] drin), das Postleitzahl eine Zahl,
die Zeichenkette nicht länger als erlaubt, sind in der Liste
mit den Optionen wirklich nur die Optionen vorhanden? etc.
- Formular mit Vorschaubutton.
- Inbesonders bei Standardskripts die Felder unbenennen.
- SessionID per hidden ganz oben Formular weitergeben.
- Dieses Feld leerlassen. Verdecken mit CSS - display: none;
- BBCode enthalten?
- Maximal x Links enthalten?

Das filtert _derzeit_ die meisten ungewünschten Einträge
raus. Zusätzlich kann man noch Filtern nach Worten, mit Bayes,
dem User-Agent, eventuell IPs aussperren, Maximal x Einträge
pro Zeiteinheit zulassen, auf doppelte/ähnliche Einträge
prüfen, ... Und der beste Schutz ist eine Kopie von sich
selbst, die in endlos kurzer Zeit endlos viele nicht
gewünschte Einträge ausfiltert.


tschuess
[|8:)

Nicolai Scheer wrote:

> Dann wäre ich (und der OP bestimmt auch) Dir um ein paar Stichpunkte an
> dieser Stelle dankbar!

- Zugriffsschutz (am besten Serverseitig) da wos sinnvoll ist.
- Dynamisch erzeugte, zufällige, nichtssagende Feldnamen.
- Zufällig erzeugte Hiddenfields die der Bot bei Request ebenfalls
nicht kennen kann.
- Inhaltsprüfungen nach Notwendigkeit und im Sinnvollen Maße
z.B. über:
- Erlaubte Zeichenbereiche (Je nach erlaubten Feldinhalt)
- HTML generell verbieten (keine Notwendigkeit für HTML vom User)
oder ungefragt entfernen
- Linkmengen sinnvoll begrenzen (oder je nach Kontext verbieten)
- Bayes-Filterung
- Getrennte Behandlung von erkannten möglichen Hackangriffen
und möglichen Fehleingaben
- Andere intelligente Inhaltsprüfungen wie Badword-Filter u.a.m.
- Vermeiden bekannter Fehlerquellen im Code
- Vernünftige Datenbehandlung im DB uMFELD (Prepared Statements)
- Schutz gegen XSS (am besten gleich Serverseitig konf.)
- Akzeptabler Aufbau der gesammten Anwendung die das Formular bedient
und/oder verarbeitet.

Mir würde mit etwas Zei sicher noch mehr eifallen, aber die Arbeit
wartet und das was ich brauche hab ich Betriebsfertig in nen paar
Klassen gekapselt wo ich nicht mehr drüber Nachdenken brauch.

Wenn man das alles zu einem vernünftigen Packet zusammen schnürt ist man
bereits ausreichend geschützt. 100% Schutz gibts nicht. Schutz mit
Abstrichen für den Besucher ist sinnfrei, da man sich ja an diesen
richtet. Klar kann man dem zeigen das man keine Ahnung von Formularen
hat und nur mit Captcha denkt auf der sicheren Seite zu sein. Aber ob
man das will? :-)

Und bevor Du jetzt wie viele Andere auch sagst das würde nicht reichen.
Ich baue wöchentlich einige Formulare. Das was da an Spam reinkommt
wurde von Hand ins Formular eingegeben und weist keine typischen
Spam-Merkmale auf bzw. ist in öffentlichen Blacklists und anderen Listen
noch nicht bekannt. Aber ich denke 1-2 Spammails pro Woche sind kein
Problem. Da kommen mehr über unbekannte Kanäle ohne das Formular als
Sendeinstanz an.

MfG, Ulf

--
_,
_(_p> Ulf [Kado] Kadner
\<_)
^^

steffen horst schrieb:
> Torsten Zühlsdorff wrote:

>>Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
>>existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubest=
immt.
>
> Wär mir neu, dass nicht bei jedem Aufruf von
>
> fopen("http://example.com/register.php?name=3Da$i&mail=3Da$i [at] example.co=
m",'r');
>
> ein neues Formular erstellt wird. :)

Wen du statt $_REQUEST nur $_POST auswertest, ist eine solche
Flood-Attacke schonmal nicht möglich. In der Regel reicht dann schon ei=
n
Feld mit zufälligem Namen, um automatische Zugriffe zu minimieren (ganz=

verhindern kann man sie damit nicht).

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------

steffen horst schrieb:
> Torsten Zühlsdorff wrote:
>> steffen horst schrieb:
>>> Ulf Kadner wrote:
>>>> steffen horst wrote:
>>>>> bei vielen Webseiten ist es (schätzungsweise) möglich, durch z.B. ein
>>>>> einfaches Script unzählige Datenbankeinträge zu erzeugen
>>>>> (Gästebucheinträge, Benutzeranmeldungen oder was auch immer). Wie
>>>>> schützt Ihr Eure Webseiten dagegen?
>>>> Gegen was denn? Gegen das Script das was in der DB macht? Lösch es einfach..
>>> Nein. Diese Antwort ist keine Antwort auf meine Frage. Also nochmal
>>> anders (im Inhalt aber dasselbe!): Womit verhindert Ihr einen
>>> maschinellen Massenzugriff auf Eure Scripte? Es gibt ja typischerweise
>>> PHP-Scripte, welche nach einer bestimmten Benutzereingabe
>>> (üblicherweise über eine HTML-Formular) eine eMail absenden oder einen
>>> Datenbankeintrag erzeugen. Welche Schutzmechanismen gibt es dagegen,
>>> dass dieses massenhaft aufgerufen wird und so z.B. eine Flut von
>>> eMails versendet?
>>>
>>> Eine Möglichkeit wäre, Captchas einzubauen. Diese werden jedoch auch
>>> (sinnvollerweise) von der Mehrheit abgelehnt.
>>>
>>> Also - welche weiteren Schutzmechanismen gibt es?
>> Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
>> existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.
>
> Wär mir neu, dass nicht bei jedem Aufruf von
>
> fopen("http://example.com/register.php?name=a$i&mail=a$i [at] exa mple.com",'r');
>
> ein neues Formular erstellt wird. :)

Aja. Wer REQUEST verwendet, anstelle von POST und Get ist selbst schuld.
Außerdem hast du meinen Punkt ignorierst: die Feldnamen, nicht das
Formular. Das heißt, dass beim ersten Aufruf das Mailinput-Feld PXAF2
und beim zweiten WEVW§4 heißt.

Gruß,
Torsten

Torsten Zühlsdorff wrote:
>steffen horst schrieb:
>> Torsten Zühlsdorff wrote:
>>> steffen horst schrieb:
>>>> Also - welche weiteren Schutzmechanismen gibt es?
>>> Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
>>> existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.
>>
>> Wär mir neu, dass nicht bei jedem Aufruf von
>>
>> fopen("http://example.com/register.php?name=a$i&mail=a$i [at] exa mple.com",'r');
>>
>> ein neues Formular erstellt wird. :)
>
>Aja. Wer REQUEST verwendet, anstelle von POST und Get ist selbst schuld.
>Außerdem hast du meinen Punkt ignorierst: die Feldnamen, nicht das
>Formular. Das heißt, dass beim ersten Aufruf das Mailinput-Feld PXAF2
>und beim zweiten WEVW§4 heißt.

Du hast recht, ich hab den Punkt tatsächlich überlesen (sorry). Die
Feldnamen, sollten die in der Session gespeichert werden? Also in
etwa:

$name = substr(base64_encode(md5(rand())), 0, 4);
$mail = substr(base64_encode(md5(rand())), 0, 4);

$_SESSION['form'] = compact('name', 'mail');

Schöne Grüße, Steffen

> $name = substr(base64_encode(md5(rand())), 0, 4);
> $mail = substr(base64_encode(md5(rand())), 0, 4);

Ich habe ein Script, in dem per CSS versteckte Felder den
verschlüsselten Namen der richtigen Variabeln enthalten. Nach meiner
Erfahrung sollte man zusätzlich noch in mindestens einem Feld, das auf
jeden Fall geändert wird, einen Standardwert setzen, der ebenfalls zur
Ablehnung führt, wenn er stehen bleibt. Klappt hier in einem Gästebuch
super.

steffen horst schrieb:

>>>>> Also - welche weiteren Schutzmechanismen gibt es?
>>>> Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
>>>> existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.
>>> Wär mir neu, dass nicht bei jedem Aufruf von
>>>
>>> fopen("http://example.com/register.php?name=a$i&mail=a$i [at] exa mple.com",'r');
>>>
>>> ein neues Formular erstellt wird. :)
>> Aja. Wer REQUEST verwendet, anstelle von POST und Get ist selbst schuld.
>> Außerdem hast du meinen Punkt ignorierst: die Feldnamen, nicht das
>> Formular. Das heißt, dass beim ersten Aufruf das Mailinput-Feld PXAF2
>> und beim zweiten WEVW§4 heißt.
>
> Du hast recht, ich hab den Punkt tatsächlich überlesen (sorry). Die
> Feldnamen, sollten die in der Session gespeichert werden?

Die Session wäre ein möglicher Ort dafür, ja.

Gruß,
Torsten

steffen horst schrieb:

> Die Frage ist:
> wie schützt Ihr Eure Webseiten gegen solche Massenzugriffe?

Warum sollte man so bekloppt sein, ein Skript ins Netz zu stellen, über das
man auf diese Weise Accounts anlegen kann?

Das ist ja fast so dämlich wie include($_GET['xxs']);

Martin

Christoph Herrmann schrieb:

> So würdest die Zeiträume und die Last
> etwas vermindern. Würde ein Benutzer dann durch starke "Aktivität"
> auffallen, könnte man Ihn ja sperren.

Auf Unterstellungen basierende Restriktionen aufgrund von Hypothesen würde
ich meinen Usern nicht zumuten.

Martin

Torsten Zühlsdorff schrieb:

> Wie wäre es mit Unique-Formularen? Jeder Name eines Inputfeldes
> existiert nur einmal und wird zufällig bei jedem Seitenaufbau neubestimmt.

Auch wenn der OP es nicht glauben mag, bei mir funktioniert dieses Prinzip
seit Jahren zuverlässig. Mein Forum ist seither Spamfrei.

Martin

Niels Braczek schrieb:

> Wen du statt $_REQUEST nur $_POST auswertest, ist eine solche
> Flood-Attacke schonmal nicht möglich.

Natürlich ist so etwas auch mit POST möglich. Nur nicht ganz so einfach,
aber auch nicht sehr viel schwerer.

Martin

steffen horst schrieb:

> $_SESSION['form'] = compact('name', 'mail');

Ich würde es ganz unkompliziert machen:

$_SESSION['mail']=$mail;
$_SESSION['name']=$name;

Vor allem dadurch, dass Spammer das vorhergehende Formular umgehen, haben
sie keine Chance, ihre Inhalte loszuwerden. Das klappt besser als Captchas
und ist im Gegensatz zu letzteren überhaupt nicht lästig, weil der User
davon gar nichts mit bekommt.

Martin

Helmut Hullen schrieb:

> http://www.heise.de/newsticker/meldung/98097/

Herbert Wehner soll mal gesagt haben: "Wenn der Schwanz steht, ist der Kopf
im Ascheimer."

Menschen (hier Männer) sind eben ausgesprochen manipuliertbar.

Martin

Hi!

Ulf Kadner schrieb:

> Und bevor Du jetzt wie viele Andere auch sagst das würde nicht reiche=
n.
> Ich baue wöchentlich einige Formulare. Das was da an Spam reinkommt
> wurde von Hand ins Formular eingegeben und weist keine typischen
> Spam-Merkmale auf bzw. ist in öffentlichen Blacklists und anderen Lis=
ten
> noch nicht bekannt. Aber ich denke 1-2 Spammails pro Woche sind kein
> Problem. Da kommen mehr über unbekannte Kanäle ohne das Formular al=
s
> Sendeinstanz an.

Doch, reicht vollkommen :)
Danke für die Denkanstöße!

Grüße,

Nico

Martin Lemke schrieb:
> Auf Unterstellungen basierende Restriktionen aufgrund von Hypothesen würde
> ich meinen Usern nicht zumuten.

Wenn ein User ein Tag lang alle 5 Minuten ein Forumseintrag schreibt
oder ähnliches sollte man es sich halt mal anschauen...

--
Mit freundlichen Grüßen,
Christoph Herrmann

http://dragonprojects.de/

Martin Lemke wrote:
>steffen horst schrieb:
>
>> Die Frage ist:
>> wie schützt Ihr Eure Webseiten gegen solche Massenzugriffe?
>
>Warum sollte man so bekloppt sein, ein Skript ins Netz zu stellen, über das
>man auf diese Weise Accounts anlegen kann?

Diese Antwort ist unwichtig. Falls es Dir entgangen sein sollte: es
geht darum, Techniken aufzulisten, mit welchen solche Lücken vermieden
werden. Dass sie vermieden werden müssen, ist bereits eine Annahme im
Ausgangspost und deshalb nicht mehr zu klären.

>Das ist ja fast so dämlich wie include($_GET['xxs']);

Nein, mit include $_GET['a']; veröffentlichst Du alle sensiblen
Benutzerdaten und die Seite geht womöglich offline.

schöne grüße, steffen

Martin Lemke schrieb:
> Niels Braczek schrieb:
>
>> Wen du statt $_REQUEST nur $_POST auswertest, ist eine solche
>> Flood-Attacke schonmal nicht möglich.
>
> Natürlich ist so etwas auch mit POST möglich. Nur nicht ganz so ein=
fach,
> aber auch nicht sehr viel schwerer.

Richtig, einen vollständigen Schutz gibt es nur mit Hilfe von
Elektromagneten direkt an der Festplatte. Mit der beschriebenen Methode
filtert man aber erfolgreich 99% der Skriptkiddies aus. Den Rest jagt
man durch einen Bayes-Filter.

MfG
Niels

--
| 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 =
|
------------------------------------------------------------ ------

* Helmut Hullen wrote:

> http://www.heise.de/newsticker/meldung/98097/

Ich schrieb "begrenzter" Schutz.
Und die Chance steigt, wenn es eben keine fertigen Captchas sind,
sondern selbstgebaute. ich verwendete zB Bilder von Tieren und der
Benutzer muß den Namen des Tieres auf dem Bild eintragen.

G.

--
BM Computer-Services, Bergmannstr. 66, 10961 Berlin
Webdesign, Internet, Layout und Grafik
Tel.: 030/20649400, mobil 0175/7419517, Fax: 030/20649401
Web: http://www.bmservices.de, eMail: kontakt [at] bmservices.de

Gerome Muent schrieb:

> Und die Chance steigt, wenn es eben keine fertigen Captchas sind,
> sondern selbstgebaute. ich verwendete zB Bilder von Tieren und der
> Benutzer muß den Namen des Tieres auf dem Bild eintragen.

Wenn Du Dich auf die "gängigen" Haustiere wie Hund, Katze, Pferd, Maus
u.ä. beschränkst, mag das ja noch gehen. Bei Gepard, Leopard und Panther
dürften etliche Besucher aber schon leicht überfordert sein.

Eine derart kleine Anzahl von Tieren ist aber kein Schutz, denn die sind
schnell ermittelt und in eine Liste eingetragen. Der Rest ist ein
Kinderspiel.

Gruß. Claus

Claus Reibenstein schrieb:
> Gerome Muent schrieb:

>> Und die Chance steigt, wenn es eben keine fertigen Captchas sind,
>> sondern selbstgebaute. ich verwendete zB Bilder von Tieren und der
>> Benutzer muß den Namen des Tieres auf dem Bild eintragen.

> Wenn Du Dich auf die "gängigen" Haustiere wie Hund, Katze, Pferd, Maus
> u.ä. beschränkst, mag das ja noch gehen. Bei Gepard, Leopard und Panther
> dürften etliche Besucher aber schon leicht überfordert sein.

Mal davon abgesehen, dass ein Sehbehinderter gar nichts davon hat und
hier raten muss, gibt es je nach Zielgruppe wahrscheinlich auch genug
Idioten die Fert, Katse oder Hunt schreiben. Ist ein mehr oder weniger
wirksamer Deppentest. Die gesteigerte Form davon sind Rechenaufgaben :)

> Eine derart kleine Anzahl von Tieren ist aber kein Schutz, denn die sind
> schnell ermittelt und in eine Liste eingetragen. Der Rest ist ein
> Kinderspiel.

Ja. Wahrscheinlich macht sich sowieso keiner die Arbeit, weil es genug
andere Formulare zum spammen gibt, die gar keine wirksamen Maßnahmen
dagegen treffen. Somit spart der Spammer Zeit und Traffic.

Auf dieser Annahme basiert ja auch die hier verbreitete Meinung, dass
wechselnde Formularbezeichner ein ausreichender Schutz sind. Es ist
natürlich auch für einen Automaten kein wirkliches Problem das Formular
erstmal zu lesen und dann eben mit den aktuellen Bezeichnern zurück zu
senden. Captchas (ob jetzt visuell oder akkustisch) sind m.E. die
größere Hürde für einen Automat. Sie sind leider aus Usability-Gründen
nicht wirklich sinnvoll.

--
"Faulheit ist die Wurzel allen Fortschritts!"
(Inhalt eines Knallbonbons, 2002)

Gerome Muent schrieb:

> Und die Chance steigt, wenn es eben keine fertigen Captchas sind,
> sondern selbstgebaute. ich verwendete zB Bilder von Tieren und der
> Benutzer muß den Namen des Tieres auf dem Bild eintragen.

Es gibt sicher nicht viele Benutzer, die den Namen zB. deines Hundes kenn=
en.

MfG
NIels

--
| 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 =
|
------------------------------------------------------------ ------

steffen horst schrieb:

> Diese Antwort ist unwichtig. Falls es Dir entgangen sein sollte: es
> geht darum, Techniken aufzulisten, mit welchen solche Lücken vermieden
> werden.

Deshalb schrieb ich ja, dass so etwas ein Fehler sei.

Warum fragst Du nach Techniken, Angriffspunkte in vom Ansatz her unsicheren
Skripten zu eliminieren? Es wäre allemal sinnvoller, ein Skript zu
erstellen, das diese Angriffspunkte gar nicht erst nicht aufweist.

Martin

Christoph Herrmann schrieb:

> Wenn ein User ein Tag lang alle 5 Minuten ein Forumseintrag schreibt
> oder ähnliches sollte man es sich halt mal anschauen...

OK, in dem Extremfall wäre das vielleicht gerechtfertigt. Allerdings sind
bei Hypothesen die Grenzfälle immer heikel. Wenn ein Spammer jeden Tag 4
Postings schickt, ist die Entwicklung eines solchen Schutzmechanismusses
vertane Zeit oder die gängelst damit unnötig legitime Poster. Damit liegt
der Schaden höher als der Nutzen.

Martin