PHP: Wie schützt man sich vor unerwartetem $_POST im Formular
0 
Marc Reichelt
0 0 molily
3 0 0 0 molily
0
0 0 0
PHP: Wie schützt man sich vor unerwartetem $_POST im Formular
Hallo,
ich habe mir überlegt, dass ja jemand ein Formular erstellen könnte, das als action= meine .php Seite angibt und meinen Auswertungsmechanismus mit unerwarteten $_POST's manipulieren könnte. Nun meine Frage ist recht simpel: gibt es wirksame Methoden, sich gegen soetwas zu schützen, ausser den $_POST mühsam zu überprüfen und das ganze dann abzubrechen, wenn nicht erwartetes ankommt?
Grüße
-
Hallo,
ich habe mir überlegt, dass ja jemand ein Formular erstellen könnte, das als action= meine .php Seite angibt und meinen Auswertungsmechanismus mit unerwarteten $_POST's manipulieren könnte. Nun meine Frage ist recht simpel: gibt es wirksame Methoden, sich gegen soetwas zu schützen, ausser den $_POST mühsam zu überprüfen und das ganze dann abzubrechen, wenn nicht erwartetes ankommt?
Nein. Benutzereingaben ist grundsätzlich zu misstrauen.
Grüße
Marc Reichelt || http://www.marcreichelt.de/
--
DPRINTK("Last time you were disconnected, how about now?");
linux-2.6.6/drivers/net/tokenring/ibmtr.c
Selfcode: ie:{ fl:| br:> va:} ls:< fo:} rl:( n4:( ss:) de:> js:| ch:? sh:| mo:) zu:) -
Hello,
ich habe mir überlegt, dass ja jemand ein Formular erstellen könnte, das als action= meine .php Seite angibt und meinen Auswertungsmechanismus mit unerwarteten $_POST's manipulieren könnte. Nun meine Frage ist recht simpel: gibt es wirksame Methoden, sich gegen soetwas zu schützen, ausser den $_POST mühsam zu überprüfen und das ganze dann abzubrechen, wenn nicht erwartetes ankommt?
Ich rate mal, dass Du meinst, wie man sich gegen gefakte Post-Requests und damit verbundene falsche oder fehlende Parameter schützen kann?
Wenn man die POST-Methode zulässt, kann man sich gegen den Request selber gar nicht schützen, es sei denn, dass man ihn tunnelt, also überhaupt nur authentifizierte User mit ihrem Client an den Server heranlässt.
Sonst kannst Du z.B. mit Zugangsschlüsseln arbeiten, die der Client sich kurz vorher mit dem Request holen muss. Das führt aber zu einem hohen Verwaltungsaufwand, da sowohl alle verbrauchten Schlüssel, als auch alle noch nicht abgelaufenen zur Verbesserung der Fehlererkennung gespeichert werden sollten.
Als Basis arbeitet man dann sowieso mit einer Session. In der Session ist bekannt, welche Dialog-Elemente man dem Client gesendet hat und welche man davon zurück erwartet. Denke daran, dass Radiogroups, Checkboxen und Selcts nur dann zurückkommen, wenn sie auch benutzt wurden. Da musst Du ja eventuell sowieso die Fehlanzeige auffüllen mit "false"...
Liebe Grüße aus Syburg
Tom vom Berg
-
Sonst kannst Du z.B. mit Zugangsschlüsseln arbeiten, die der Client sich kurz vorher mit dem Request holen muss. Das führt aber zu einem hohen Verwaltungsaufwand, da sowohl alle verbrauchten Schlüssel, als auch alle noch nicht abgelaufenen zur Verbesserung der Fehlererkennung gespeichert werden sollten.
Nein, wieso?
Als Basis arbeitet man dann sowieso mit einer Session.
Die alleine nicht vor CSRF schützt.
Mathias
-
-
Moin!
ich habe mir überlegt, dass ja jemand ein Formular erstellen könnte, das als action= meine .php Seite angibt und meinen Auswertungsmechanismus mit unerwarteten $_POST's manipulieren könnte. Nun meine Frage ist recht simpel: gibt es wirksame Methoden, sich gegen soetwas zu schützen, ausser den $_POST mühsam zu überprüfen und das ganze dann abzubrechen, wenn nicht erwartetes ankommt?
Jeder Request kommt für den Webserver und dessen Skripte "unerwartet", weil HTTP keinerlei Zustandsbehaftung hat. Jeder Request steht für sich alleine, es gibt kein "vorher war aber..." und kein "hinterher muss noch...".
Von dieser Feststellung ausgehend ist die Überlegung also folgende: Wenn die in $_POST gesendeten Daten zu einer sinnvolle Aktion des Skripts führen können, dann gibts keinen Weg, das abzubrechen oder zu vereiteln, weil ja genau dafür das Skript da ist.
Die einzige Chance liegt darin, die Anforderungen an "sinnvolle Daten in $_POST" bzw. generell in allen beim Request mitgesendeten Informationen so stringent zu formulieren, dass nur noch die gewünschte Untermenge aller denkbaren Requests durchkommt, die man haben will.
Das Problem dabei ist: Alle Informationen, die ein Formular-Ausgabe-Skript vorher versteckt in das Formular hineintut, sind öffentlich abrufbar - also kann das POST-manipulierende Skript diese Informationen abfragen und wieder zurücksenden. Das gilt auch für jede Art von Session-Mechanismus. Einzig ein Passwortschutz wäre eine einigermaßen wirksame Hürde, sofern man nicht automatisiert an neu generierte Accounts kommt.
Damit das so automatisch generiert nicht mehr funktioniert, gibt es CAPTCHA. Diese Tests, meist in Form irgendwelcher verzerrten Textbildchen, deren Buchstaben wieder einzutippen sind, sollen die heutigen Bildtexterkennungen überfordern, aber von Menschen leicht lösbar sein.
Das ist dummerweise ein Zielkonflikt. Die Textbilder sind oftmals auch für normalsichtige Menschen kaum lösbar, für Menschen ohne normale Augenfunktion erst recht nicht. Hingegen sind schlechte CAPTCHA-Bilder sehr wohl automatisiert von Programmen lösbar, oder man setzt als Automatisierer einfach menschliche Rechenpower ein, indem man das CAPTCHA-Bild einfach auf einer ganz anderen Seite anzeigt, die unter dem Mott läuft: "Lös mir das CAPTCHA, und ich zeig' dir pr0n!".
Irgendwo auf der Skala von "automatisiert nutzbar" bis "auch durch Menschen nicht mehr nutzbar" rangiert jedes Formular. Die Frage ist jeweils: Welchen Nutzen kann man daraus ziehen, was kann man gewinnen, wenn man das Formular evtl. massenhaft oder manipuliert an den Server zurückschickt?
Das Ziel einer vernünftigen Skriptprogrammierung sollte also sein, den anrichtbaren Schaden gering zu halten, bzw. bei abnormer Nutzung in irgendeiner Weise ein Alarmsignal an den Admin zu senden.
- Sven Rautenberg
-
Ahoi,
ich habe mir überlegt, dass ja jemand ein Formular erstellen könnte, das als action= meine .php Seite angibt und meinen Auswertungsmechanismus mit unerwarteten $_POST's manipulieren könnte. Nun meine Frage ist recht simpel: gibt es wirksame Methoden, sich gegen soetwas zu schützen, ausser den $_POST mühsam zu überprüfen und das ganze dann abzubrechen, wenn nicht erwartetes ankommt?
$zugelassen = array("name","mail","adresse");
foreach ($_POST as $key =>$value) {
if (!in_array($key,$zugelassen) unset($_POST[$key]);
}
ist nicht mühsam, wenn auch ungetestet.oder beim speichern der Daten dasselbe Spiel, zb wenn nicht im Array der Spaltennamen. Dabei filterst du aber nur die keys, nicht den Inhalt.
Dank und Gruß,
-
Dabei filterst du aber nur die keys, nicht den Inhalt.
Muss man noch irgenwas spezielles einplanen oder ist mit mysql_real_escape_string() und htmlspecialchars() erstmal genug geprüft wenn man das ganze in eine mysql datenbank schreibt?
-
ist mit mysql_real_escape_string() und htmlspecialchars() erstmal genug geprüft wenn man das ganze in eine mysql datenbank schreibt?
htmlspecialchars ist für das Speichern in der Datenbank zuviel des Guten.
Mathias
-
htmlspecialchars ist für das Speichern in der Datenbank zuviel des Guten.
Seh ich mittlerweile auch so, beim Auslesen und Einfügen in den HTML code zu überprüfen reicht wohl, wenn man HTML Tags nicht 1:1 in in der Datei haben will.
-
-
-
Guten Tag,
$zugelassen = array("name","mail","adresse");
foreach ($_POST as $key =>$value) {
if (!in_array($key,$zugelassen) unset($_POST[$key]);
}Das geht mit array_intersect auch einfacher :-)
Gruß
Christoph Jeschke--
Zend Certified Engineer
Certified Urchin Admin-
Ahoi,
Das geht mit array_intersect auch einfacher :-)
kapier ich nicht. Wer intersected denn dann mit wem?
<?php
$array1 = array("a" => "green", "red", "blue");
$array2 = array("b" => "green", "yellow", "red");
$result = array_intersect($array1, $array2);
print_r($result);
?>The above example will output:
Array
(
[a] => green
[0] => red
)welches wäre das Post-Array, welches das Zugelassene_Keys_Array?
Dank und Gruß,
-
-
-
Hallo Blümchen,
indem man keine unerwarteten $_POST zuläßt!
Dazu gibt es zwei Wege:a - _alle_ Variablen des Scripte werden initialisiert!
Uninitialisierte Variablen werden nicht verwendet.
Alle includierten Scripte werden auf Einhaltung der Vorgabe kontrolliert.b - "unerwartete" Requests werden im Ablauf nicht zugelassen.
Dazu verwendet man eine zeitlich streng begrenzte Form-ID,
welche erst beim Aufruf dynamisch erzeugt wird.
Wer zu spät kommt, hat das Nachsehen ...Die Kombination der Methoden sollte den gewünschten Effekt bringen.
m.b.G. Rolf
-
Ahoi,
a - _alle_ Variablen des Scripte werden initialisiert!
Uninitialisierte Variablen werden nicht verwendet.
Alle includierten Scripte werden auf Einhaltung der Vorgabe kontrolliert.Was heißt das im Zusammenhang mit $_POST?
b - "unerwartete" Requests werden im Ablauf nicht zugelassen.
Dazu verwendet man eine zeitlich streng begrenzte Form-ID,
welche erst beim Aufruf dynamisch erzeugt wird.
Wer zu spät kommt, hat das Nachsehen ...Meinst Du eine Session?
Dank und Gruß,
-
Hallo,
»» a - _alle_ Variablen des Scripte werden initialisiert!
»» Uninitialisierte Variablen werden nicht verwendet.
»» Alle includierten Scripte werden auf Einhaltung der Vorgabe kontrolliert.
Was heißt das im Zusammenhang mit $_POST?Was Du wolle ... <grübel>
»» b - "unerwartete" Requests werden im Ablauf nicht zugelassen.
»» Dazu verwendet man eine zeitlich streng begrenzte Form-ID,
»» welche erst beim Aufruf dynamisch erzeugt wird.
»» Wer zu spät kommt, hat das Nachsehen ...
Meinst Du eine Session?im Prinzip Jain, die ID gilt nur für den singulären Aufruf des Formulars,
und läuft zusätzlich zu der aktuellen Session, falls es eine gibt.m.b.G. Rolf
-
-
-
Vielen Dank für die ausführlichen Infos!
-
ok, ich hab auch noch was:
mit dem Formular setzt Du einen Keks mit einem bestimmten Value (z.B. SCRIPT_NAME).
Wird das Formular abgeschickt, kommt der Cookie mit und serverseitig kann somit geprüft werden, dass der POST auch tatsächlich von dem Formular kommt.
Die Parameter musst Du allerdings auch hier extra prüfen.
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
mit dem Formular setzt Du einen Keks mit einem bestimmten Value (z.B. SCRIPT_NAME).
Wird das Formular abgeschickt, kommt der Cookie mit und serverseitig kann somit geprüft werden, dass der POST auch tatsächlich von dem Formular kommt.
Das erschwert Request Forgery nur minimal. Wenn der Angreifer das heraushat, lässt er den Browser des Anwenders einfach das Formular abrufen und den Cookie abholen, bevor er ihn Daten an die zweite URI schicken lässt.
Mathias
-
moin,
»» mit dem Formular setzt Du einen Keks mit einem bestimmten Value (z.B. SCRIPT_NAME).
»»
»» Wird das Formular abgeschickt, kommt der Cookie mit und serverseitig kann somit geprüft werden, dass der POST auch tatsächlich von dem Formular kommt.Das erschwert Request Forgery nur minimal. Wenn der Angreifer das heraushat, lässt er den Browser des Anwenders einfach das Formular abrufen und den Cookie abholen, bevor er ihn Daten an die zweite URI schicken lässt.
Feilich. Aber solch ein Ansatz kann ja noch gesteigert werden; z.B. kann ein Formular mit 2 unterschiedlichen Session-Keys, von denen einer per header in den Cookie gesetzt und der andere per Ajax generiert wird, dermaßen "verrammelt" werden, so dass es wirklich schwierig wird, einen POST auf den Server zu schicken, sofern dieser nicht explizit von _dem_ Formular kommt, welches da erst im Browser aufgerufen werden muss. Eine zusätzliche zeitliche Sperre zwischen dem "GET-Formular" und "POST-Data" und die Begrenzung auf "einen POST per Session" könnte schonmal einen Großteil der Spammer abwimmeln, die das automatisiert tun wollen.
Hotte
--
Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.-
Aber solch ein Ansatz kann ja noch gesteigert werden; z.B. kann ein Formular mit 2 unterschiedlichen Session-Keys, von denen einer per header in den Cookie gesetzt und der andere per Ajax generiert wird
Diese Steigerung ist im Vergleich zu seinem Nutzen unnötig kompliziert. Sie hat dieselbe Sicherheit wie das serverseitige Schreiben eines Tokens in ein verstecktes Eingabefeld. Ein Angreifer kann sich Cookie-Token und Ajax-Token ebenfalls automatisiert holen, es fordert ihm nur eine Minute mehr Aufwand ab.
Ob der Token direkt ins Formular geschrieben wird oder erst per Ajax geholt wird, ist insofern ziemlich gleich. Beides verhindert CSRF, erschwert Spamming aber nur wenig. Letzteres macht nur das Formular für ehrliche Benutzer ohne JavaScript nicht bedienbar.
Mathias
-
Hello,
was mich interessieren würde:
Wird ein Robot, der mir etwas in mein Formular postet, auf die Antwort warten, dass der Eintrag erfolgreich war? Oder wird der einfach nur den Post-Request absetzen und dann zum nächsten weiterziehen?
Liebe Grüße aus Syburg
Tom vom Berg
-
Ahoi,
Wird ein Robot, der mir etwas in mein Formular postet, auf die Antwort warten, dass der Eintrag erfolgreich war? Oder wird der einfach nur den Post-Request absetzen und dann zum nächsten weiterziehen?
So arbeitet Felix Riesteres Gästebuch. Nach dem Abschicken kommt erst die Vorschau. Man muss zweimal abschicken. Die Bot-Erfahrungen sind wohl positiv.
Was mich aber interessiert: Bots können doch kein Javascript. Wenn ich einen individuelles Javascriptfeld platziere (tiny-capture) ist der Bot doch aus dem Rennen.
Dank und Gruß,
-
hi,
Was mich aber interessiert: Bots können doch kein Javascript.
^noch
ist die Frage ;)
Fluppe,
Hotte--
# hier könnte ihr Kommentar stehen. -
Hello,
Wird ein Robot, der mir etwas in mein Formular postet, auf die Antwort warten, dass der Eintrag erfolgreich war? Oder wird der einfach nur den Post-Request absetzen und dann zum nächsten weiterziehen?
So arbeitet Felix Riesteres Gästebuch. Nach dem Abschicken kommt erst die Vorschau. Man muss zweimal abschicken. Die Bot-Erfahrungen sind wohl positiv.
Ich wollte auf etwas anderes hinaus.
Wenn der Bot nicht waret (so. ca. 2-5 sec), dann könnte man aus dem verfrühten User-Abort ableiten, dass gar nicht gespeichert wird.Liebe Grüße aus Syburg
Tom vom Berg
-
Hoi.
Was mich aber interessiert: Bots können doch kein Javascript.
Verallgemeinerungen sind immer sone Sache...
Grüße
-
Ahoi,
Hoi.
»» Was mich aber interessiert: Bots können doch kein Javascript.
Verallgemeinerungen sind immer sone Sache...
War aber dem Fall schon so gemeint. Wenn Google nichtmal Javascript kann, wie soll das ein herkömmlicher Bot können? Deshalb Tippe ich, das kann kein Bot.
Dank und Gruß,
-
Yerf!
War aber dem Fall schon so gemeint. Wenn Google nichtmal Javascript kann, wie soll das ein herkömmlicher Bot können?
Welches Interesse hätte Google darin, Javascript zu verarbeiten? ...und welches Interesse könnte bei einem Bot-Benutzer da sein?
Deshalb Tippe ich, das kann kein Bot.
Technisch ist es überhaupt kein Problem einem Bot JavaScript beizubringen. Einfach eine fertige Browser-Engine nehmen und per eigenem Code steuern. Dann hat man alles, was ein "echter" User auch hat: CSS, JS, Cookies usw.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Yerf!
War aber dem Fall schon so gemeint. Wenn Google nichtmal Javascript kann, wie soll das ein herkömmlicher Bot können?
Tja wir dachten auch immer:
Google wird niemals Formularen folgen
Google plant aber genau dies zu tun.Welches Interesse hätte Google darin, Javascript zu verarbeiten? ...und welches Interesse könnte bei einem Bot-Benutzer da sein?
Als eine voraussetzung, um Formularen zu folgen wird wohl auch Javascript angewendet.
Ein Browser ist ein ein JS fähiger Bot.
Technisch ist es überhaupt kein Problem einem Bot JavaScript beizubringen. Einfach eine fertige Browser-Engine nehmen und per eigenem Code steuern. Dann hat man alles, was ein "echter" User auch hat: CSS, JS, Cookies usw.
Genau. Die Grenzen zwischen Bot und User-Agent sind nämlich recht fliessend geworden.
mfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische-
Hello,
Tja wir dachten auch immer:
Google wird niemals Formularen folgen
Google plant aber genau dies zu tun.Kannst Du das bitte mit etwas mehr faktischem Hintergrund versehen?
Das interessiert mich.Sollen da auch die action-Attribute als Link aufbereitet werden?
Das hätte verheerende Folgen.Liebe Grüße aus Syburg
Tom vom Berg
-
Tja wir dachten auch immer:
Google wird niemals Formularen folgen
Google plant aber genau dies zu tun.Kannst Du das bitte mit etwas mehr faktischem Hintergrund versehen?
Das interessiert mich.google PDF dazu
http://www.cs.cornell.edu/~lucja/Publications/I03.pdfmfg Beat
--
><o(((°> ><o(((°>
<°)))o>< ><o(((°>o
Der Valigator leibt diese Fische
-
-
-
Ahoi,
Welches Interesse hätte Google darin, Javascript zu verarbeiten? ...und welches Interesse könnte bei einem Bot-Benutzer da sein?
Angeborener Informationsdurst?
Technisch ist es überhaupt kein Problem einem Bot JavaScript beizubringen. Einfach eine fertige Browser-Engine nehmen und per eigenem Code steuern. Dann hat man alles, was ein "echter" User auch hat: CSS, JS, Cookies usw.
Wenn man ohne dieses Feature genug einfängt? Welches Interesse könnte Bot haben, Javascript zu verarbeiten?
Dank und Gruß,
-
Yerf!
Wenn man ohne dieses Feature genug einfängt? Welches Interesse könnte Bot haben, Javascript zu verarbeiten?
Momentan mag es noch ein Schutz sein. Sobald bei genügend Formularen JavaScript zum Einsatz kommt werden die Bots nachziehen.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Ahoi,
Yerf!
»» Wenn man ohne dieses Feature genug einfängt? Welches Interesse könnte Bot haben, Javascript zu verarbeiten?
Momentan mag es noch ein Schutz sein. Sobald bei genügend Formularen JavaScript zum Einsatz kommt werden die Bots nachziehen.
Aber das ist ja das "spiel", oder? Zumindest bei den Captchas. Und dann wiederum ist "security by individuality" durchaus ein probates Mittel, denn Bots orientieren sich ja an dem Massenfraß.
Dank und Gruß,
-
Yerf!
Aber das ist ja das "spiel", oder? Zumindest bei den Captchas. Und dann wiederum ist "security by individuality" durchaus ein probates Mittel, denn Bots orientieren sich ja an dem Massenfraß.
Ja. Ich wollte nur darauf hinweisen, dass man eine gewählte Lösung hin und wieder mal überprüfen sollte, ob sie immernoch "individuell" ist oder ob inzwischen jeder so Arbeitet und sich die Bots inzwischen drauf eingestellt haben.
Gruß,
Harlequin
--
<!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->-
Ahoi,
Ja. Ich wollte nur darauf hinweisen, dass man eine gewählte Lösung hin und wieder mal überprüfen sollte, ob sie immernoch "individuell" ist oder ob inzwischen jeder so Arbeitet und sich die Bots inzwischen drauf eingestellt haben.
Ja, das merkt man ja spätestens dann, wenn es ganz viele Einträge im Gästebuch oder Kommentar gibt mit lauter Links auf russische Pornoseiten (;-).
Dank und Gruß,
-
-
-
-
-
-
-
Hello,
Verallgemeinerungen sind immer sone Sache...
Ein 08/15 Spambot ist doch vielelicht sogar in PHP geschrieben.
Der liest z.B. mit file_get_contents() die Seite ein, stellt fest, ob ein <form>-Element enthalten ist, extrahiert mit ein paar dummen regexps die Dialogelemente und dann?
Dann benötigt er ein fsockopen(), um den Post-Request abzusetzen.
Ich habe eben nochmal alle Beispiele durchgeschaut, die ich so in den Jahren gesammelt habe. Es wird leider immer auf Antwort gewartet, auch wenn die nicht immer ausgewertet wird.
Die ausgeklügelten werten zumindest die Response-Header aus, um ggf. auf Weiterleitungen oder Fehlerstatus reagieren zu können.
Dann muss ich also davon ausgehen, dass der Spam-Bot die Verbindung nicht vorzeitig kappt.
Die wartende Instanz benötigt auf dem Server ja auch kaum Power, nur etwas Speicher.Schade! Ist also vermutlich keine Methode, um Spambots zu ärgern.
Liebe Grüße aus Syburg
Tom vom Berg
-
-
-
Hoi.
Wird ein Robot, der mir etwas in mein Formular postet, auf die Antwort warten, dass der Eintrag erfolgreich war? Oder wird der einfach nur den Post-Request absetzen und dann zum nächsten weiterziehen?
It depends from the robot... Auf 08/15 Spambots wird letzteres zutreffen.
Grüße
-
-
-
-
-