[PHP] Nach einem Formular prüfen, von welcher Domain die Daten kommen?

[SireMcDeath]

Hi!

Wie kann ich mit Hilfe von PHP checken, ob die übergebenen Werte aus einem Formular wirklich von dem Formular auf MEINER Seite kommen und das Formular nicht woanders aufgerufen wurde...

Referer? Wie geht das am besten? Gibts da ne Möglichkeit in htaccess, um Zugriffe nur von meiner Seite zu gestatten?

Merci

 

[Icy]

Mittels

$_SERVER["HTTP_REFERER"]

oder du generierst beim Aufruf des Formulares dynamisch lange nur einmal gültige IDs und packst sie in ein Hidden Feld und vergleichst nach dem Abschicken

 

[Scar]

viele browser senden falsche oder garkeine referer, drum ist das keine wirklich gute lösung.

wenn du spam verhinden willst, solltest du einfach captcha grafiken integrieren.

 

[artemissays]

Es gibt auch noch eine weitere, etwas aufwendigere Methode. Du generierst "Page Tickets".

Sobald ein Benutzer auf deine Seite kommt generierst du erstmal paar Zahlen und speicherst sie irgendwo temporär ab.
Danach hängste diese Zahlen (immer nur eine) hinter jeden Link, also nachher via _GET wieder abrufbar.
Jede verbrauchte Zahl wird gelöscht und kannst sie entweder direkt löschen oder erst nach und nach, musst halt schaun.
Wenn die Zahl nicht übertragen wird oder sie nicht zur Session passt ist was schief gelaufen.
Ein Cronjob der dann alle paar Mins die Sachen löscht könnt auch helfen, der sollte aber nicht zu viel löschen sondern nur "veraltete" Sachen

Grüße,
artemis

 

[LasMiranda]

Es gibt auch noch eine weitere, etwas aufwendigere Methode. Du generierst "Page Tickets".

Seite einlesen, regexp, Wert anhängen

 

[SireMcDeath]

Seite einlesen, regexp, Wert anhängen

diese variante verstehe ich nicht... kannst du das etwas genauer erläutern?

 

[Icy]

Seite einlesen, regexp, Wert anhängen

Ja, ist ne Methode um den Schutz zu umgehen.

Hier eine Frage: Was ist eigendlich das Ziel? Was soll geschützt werden?

Wenn 'nur' verhindert werden soll das die Formulardaten von einer anderen Webseite kommen, um Umfragen und Bewertungen vor Manipulation zu schützen, reicht in der Tat ein Ticketsystem (was ich in ähnlicher Weise auch schon angeschnitten habe), denn die meisten Schummler baun sich, um auf Stimmenfang zu gehen, irgendwo auf einem Free Webspace ein sich automatisch abschickendes Formular und tragen die Seite in ein Besuchertauschsystem ein.

Soll jedoch sichergestellt werden, das das Formular wirklich von einem Menschen ausgefüllt wird, ist in der Tat ein Captcha oder Antibot Fallen (je nach Situation) die bessere Wahl

 

[Scar]

Es gibt auch noch eine weitere, etwas aufwendigere Methode. Du generierst "Page Tickets". [...]

is zwar ne nette idee, aber mehr auch nicht. in der regel können links mehrfach und/oder in neuen browser geöffnet werden. dann würden aber die alten IDs weiterhin auf der seite stehn und man würde beim erneuten klick ins nirvana laufen. drum dürfte sowas nur für seiten mit javascript links effektiv genutzt werden können, weil man dort genau sowas unterbinden kann.

 

[Icy]

...in der regel können links mehrfach und/oder in neuen browser geöffnet werden. dann würden aber die alten IDs weiterhin auf der seite stehn und man würde beim erneuten klick ins nirvana laufen...

Warum sollen die Klicks ins Nirvana laufen?
Wenn sie das tun, dann stimmt was am Code nicht - ruft man selber eine Seite 2x auf (oder zwei Leute rufen die Seite 1x auf - technisch das selbe Prinzip!), dann gibt es natürlich pro Aufruf eine neue ID, wobei die alte ID natürlich weiterhin gültig bleiben muss, sonst hat auch der Besucher ein Problem, der die Seite nur 1x aufruft, zwar genau dann, wenn ein anderer Besucher draufkommt und sich ne neue ID schnappt.

Und um zu verhindern, das man IDs durch pausenlose Aufrufe 'sammelt' und sie beim Faken aus der Sammeldatenbank runterrattern lässt, kann man, je wie man Lust hat, eins oder mehrere der folgenden Dinge tun:

• Zeitbeschränkung (ID ist nur bestimmte Zeit gültig)
• Max. 3 frische IDs pro IP; wird das Formular das 4. Mal aufgerufen, ohne es einmal abgeschickt zu haben, gibt es eine alte noch gültige ID aus dem Pool (recycling)
• Ticket ID an Cookie, Useragent oder IP binden, Kombinationen sind möglich
• Ticket ID an die Session ID der Sessionsteuerung des Muttersystems (z.B. VMS) binden
• HTTP_REFERER zusätzlich prüfen

 

[Scar]

wenn die ids wieder länger leben, würd es teils gehn. nur wer will schon sowas programmieren. dann doch lieber nen captcha oder text-bestätigungsfeld

 

[Icy]

dann doch lieber nen captcha oder text-bestätigungsfeld

An einem Captcha frickelt man auch eine, ich sage mal, nicht unwesentliche Zeit dran rum, bis das richtig läuft und Captchas sind nervig, bei Gästebuch vielleicht noch Ok, aber bei Umfragen übertrieben und abschreckend (gibt weniger Stimmen)