Fremde Formulare ignorieren
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
adresse
anzeigen
check
datenbank
datum
eintrag
formular
funktion
praxis
problem
regeln
register
session
setzen
sicherheitsproblem
software
sperre
sperren
umgehen
verwenden
-
Hallöchen,
ich habe ein kleines Problem, bei dem selbst mein Info-Lehrer keine Antwort wusste.
Ich hab auf meiner Website ein Gästebuch, das wohl relativ konventionell gestrickt ist:
Eine Datei mit der Form sendet die daten an ein php script, welches sie in die db legt.
Nur finde ich es irgendwie beunruhigend, dass jedes beliebige Formular, das an dieses script sendet, seinen senf in meine datenbank legen kann.
Kann man das irgendwie verhindern? Das script so konfigurieren, dass es nur daten aus dem formular meiner homepage annimmt? -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Am einfachsten über den Referrer überprüfen, ob die Seite von der Seite mit dem Formular abgesendet wurde. Oder du setzt eine Session und überprüfst, ob sie gesetzt ist. Und sag deinem Infolehrer n Gruß von mir ;)
-
Der Referer wird jedoch nicht immer gesendet. Bei meinem Browser ist das zumindest deaktiviert.
Das Problem, das du beschreibst, nennt sich Cross Site Forgery Request. Dies kann in PHP man relativ einfach umgehen, indem du beim Anzeigen des Formular eine PHP Session startest. In dieser Session speicherst du dann auch direkt die Variable $formularAngezeigt = true und wenn der Server dann ein Formular empfängt, schaust du einfach in die Session, ob die Variable $formularAngezeigt bereits existiert. Wenn ja, ist der Eintrag erfolgreich.
Nochmal schematisch:
User ruft Gästebuch auf --> Gästebuch wird angezeigt und $_SESSION[ 'formularAngezeigt' ] wird auf true gesetzt --> user schickt Formular ab --> $_SESSION Variable existiert --> Alles OK
Und der andere Fall:
User schickt Formular von fremder Seite ab --> $_SESSION Variable existiert nicht --> Nicht akzeptiert. -
Was genau ist denn eigentlich das Sicherheitsproblem. Ich finde die Problematik sehr interessant. Gut, mein echter Formular-Code ist über HTML öffentlich sichtbar. Aber wenn man im PHP-Skript die Formularfeldnamen (z.B. $_POST['name']) ausliest und abspeichert, dann können zumindest fremde Inhalte in anders benannten Formularinhalten nicht in die Datenbank o.ä. gespeichert werden. Und wenn jemand Schadcode oder was auch sonst einschleusen will, dann kann er das doch sowieso besser über mein Formular machen, als extra eine fremde Quelle zu generieren. Und dann wäre der Sessionwert automatisch auch gesetzt.
Oder blicke ich da grad das Problem nicht?
Voraussetzung ist natürlich, dass alle fremden Nutzereingaben nicht ohne Überprüfung verarbeitet werden und register globals aus sind. Bei angeschalteten register globals erschließt sich mir die / eine daraus entstehende Problematik. -
das Sicherheitsproblem ist, dass jemand einen 5Zeiler schreiben könnte, der die Datenbank des TEs vollflutet... das wirkt sich unter Umständen nicht Positiv auf Performance und später auf Verfügbarkeit aus...
-
Aber könnte derjenige das nicht viel einfacher über mein bereitgestelltes Formular machen anstatt da erst etwas externes zu coden? Außerdem sollte doch mein Skript sowieso eine Zeitsperre enthalten, damit nicht unendlich viele Daten in die Datenbank gepostet werden können.
btw: was ist ein TE? -
bladehunter schrieb:
Der Referer wird jedoch nicht immer gesendet. Bei meinem Browser ist das zumindest deaktiviert.
Da hast du leider recht, wobei das bei Ottonormalverbraucher nicht der Fall sein wird.
Dies kann in PHP man relativ einfach umgehen, indem du beim Anzeigen des Formular eine PHP Session startest.
Dann läd man in der angreifenden Webseite eben die Seite in nem iFrame oder ruft die Seite 1x aus (falls ein Spambot verwendet wird), damit die Session gesetzt wird.
Der einzige wirksame Schutz wird eine Captcha sein.
-
TE= Threadersteller
trueweb schrieb:
Der einzige wirksame Schutz wird eine Captcha sein.
ist ne gute Idee, da ist auch nix mit Daten einfluten...^^
allerdings gibt es OCR-Software, die ausreichend gut ist, leichtere Captchas zu erkennen... schwerere ist für den menschen wieder schwerer zu entziffern... ich kann bei manchen webseiten die captchas gar nicht entschlüsseln...
der Timer gehört auch rein, den sollte man aber an die session binden, damit nicht alle betroffen sind^^
über die session kann man auch regeln, dass man nicht immer das captcha braucht, weil das lästig wird...
du kannst auch nen check über die IP machen: wenn es dieselbe ist, wie beim letzten EIntrag, dann einfach die funktion sperren, quasi eine doppelpost-Sperre...
von daher ist es auch nicht sinnvoll, ein Captcha zu setzen, wenn man die IP hat... -
sebulon schrieb:
über die session kann man auch regeln, dass man nicht immer das captcha braucht, weil das lästig wird...
du kannst auch nen check über die IP machen: wenn es dieselbe ist, wie beim letzten EIntrag, dann einfach die funktion sperren, quasi eine doppelpost-Sperre...
von daher ist es auch nicht sinnvoll, ein Captcha zu setzen, wenn man die IP hat...
Ich habe in der Praxis die Erfahrung gemacht, dass professionelle Spammer sowohl verschiedene IPs als auch OCR-Software verwenden, also ist die IP-Sperre auch keine wirksame Lösung. Seitdem ich auf ReCaptcha setze, hatte ich keine Spameinträge mehr. -
trueweb schrieb:
Ich habe in der Praxis die Erfahrung gemacht, dass professionelle Spammer sowohl verschiedene IPs als auch OCR-Software verwenden, also ist die IP-Sperre auch keine wirksame Lösung. Seitdem ich auf ReCaptcha setze, hatte ich keine Spameinträge mehr.
Bei mir haben Spammer auch schon das Captcha lösen können. Und wie trueweb schrieb, wechseln die IP-Adressen im Sekundentakt. Dafür wird nun geprüft, ob eine E-Mail-Adresse - zumindest deren Domain - einen MX Eintrag hat. Somit bleibe ich von Spam im Gästebuch und Kontaktformular verschont. Ist bislang nichts dergleichen wieder durchgekommen.
@sebulon: Danke für die Erklärung. Hatte bei den ganzen technischen Begriffen gedacht, TE sei eine technische Komponente oder so. -
Ich schließe mich trueweb an: Ein Captcha dürfte die wirksamste Methode sein, um sich gegen automatisierte Eintragungen zu schützen. Hier ist reCaptcha (wie bereits erwähnt) eine gute Wahl, da dort Wörter aus alten Büchern verwendet werden, die eben nicht von gängiger OCR Software erkannt werden konnten.
Und da reCaptcha dazu verwendet wird, um Bücher zu digitalisieren, dient das ganze auch einem guten Zweck. -
Das Problem bei einer Captcha wiederum ist, dass man nicht für jede Aktion auf seiner Seite eine verwenden möchte zB für eingeloggte User. Da es aber nicht nur um Spam geht, bringt es nichts, spammende User zu löschen da evtl. der Spam von einer fremden Seite ausgeführt wird.
Wikipedia schlägt vor, ein Token (bzw. wie sies nennen: Shared-Secret) zu verwenden, wobei das von mir weiter oben beschriebene "Session per iFrame setzen"-Problem behoben wird, aber Bots können das Secret in einem Hiddenfield ebenso auslesen. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
