Spamschutz für eigene Scripte?

[2nd]

Hallo,

ich würde gerne ein PHP-Script absichern, damit es nicht per Get- bzw. POST-Injections als Instrument für Spammer missbraucht werden kann. Ich benutze die Mailfunktion von PHP, also mail(....);, nachdem die Daten von einem Formular übernommen werden.

Hat jemand eine Idee oder Anleitung, wie ich das am besten bewerkstellige?

Danke,

Frank

 

[maceis]

Da gibt es verschiedene Ansätze.

Ein Grundgedanke besteht darin, alle Benutzereingaben als potentiell verseucht zu behandeln.
Das heisst, man überlegt sich genau, welche Benutzereingaben man zulassen kann/muss/möchte und prüft dann, ob die tatsächliche Eingabe den Kriterien entspricht.

Wenn es zum Beispiel ein Feld gibt, in dem der Benutzer seine Emailadresse eingeben darf, prüft man, ob die Eingabe dem Muster einer einzielnen Emailadresse entspricht und nicht etwa so etwas beinhaltet:
"someoneelse@domain.com\nbcc: secretaddress@myhome.dom" (nur so als schnelles Beispiel)

GET würde ich bei solchen Formularen grundsätzlich nicht verarbeiten

 

[2nd]

Danke maceis.

Ich schicke die Benutzereingaben nach einer ersten Filterung durch Actionscript im Flash per Loadvars an das mailer.php Script, das passiert mittels GET, jedoch erfolgt der Ausruf aus dem SWF-File heraus. Muss ich mir da Sorgen machen?

Die Filter im Flash prüfen die Eingaben komplett durch, d. h. die eMail-Adresse auf Korrektheit und den Text.

Eine andere Sache: Wenn jemand den Namen meines mailer.php Scriptes kennt, kann man das Script dann von einer anderen Domain aus ausrufen und mit Variablen, die einen Header etc. bilden, injizieren? Das heisst, muss ich im PHP Script noch mal alles durchprüfen?

Frank

 

[maceis]

...
Eine andere Sache: Wenn jemand den Namen meines mailer.php Scriptes kennt, kann man das Script dann von einer anderen Domain aus ausrufen und mit Variablen, die einen Header etc. bilden, injizieren? Das heisst, muss ich im PHP Script noch mal alles durchprüfen?
...

Man kann das Skript grundsätzlich von einer anderen Doamin aus benutzen. Das kannst Du aber mittels einer geschickt konfigurierten .htaccess Datei weitestgehend unterbinden. (Mit Bedingungen).

Dass man zusätzliche Variablen einschmuggeln kann, die dann von Deinem Skript verarbeitet werden, ist nach meinem Kenntnisstand im Normallfall nicht möglich, es sei denn Dein Skript legt es darauf an, beliebige Variablen auszuwerten.
Was dann mit den Variablen gemacht wird, hängt auch wieder von Deinem Skript ab.

 

[moses_78]

Selbstverständlich. Clientseitig geprüften Daten sollte man nie ver-
trauen, mit Curl zum Beispiel, oder eben Telnet, kann man beliebige,
ungeprüfte Daten an Scripte schicken.

Edit: Maceis war wieder schneller, und ausführlicher....

 

[2nd]

Ok, verstehe. Dann kann ich mit einer .htaccess Datei schonmal Schindluder verhindern. Wo kann ich mich da belesen, was ich da reinschreiben muss?

Meine Variablen haben natürlich Namen, die dann per mail-Funktion weitergeschickt werden. Das jemand genau die Namen der Variablen "errät" und dann mein Script benutzt ist unwahrscheinlich oder?

Frank

 

[moses_78]

Und was, wenn der Sender des Formulars auch den Referer fälscht?

 

[maceis]

Ok, verstehe. Dann kann ich mit einer .htaccess Datei schonmal Schindluder verhindern. Wo kann ich mich da belesen, was ich da reinschreiben muss?
...

Die Basics kannst Du zB bei selfhtml nachlesen. Es gibt aber jede Menge andere Infomationsquellen.
Eine Idee wäre z.B mit einer RewriteCond den HTTP_REFERER abzufragen. Wenn es nicht deine Seite ist, leitest Du die Anfrage auf eine Fehlerseite.
Das ist zwar nicht vollständig fälschungssicher, aber den größten Teil der Roboter bist Du damit wohl los.
Grundsätzlich könnte man das auch innerhalb des Skriptes lösen, .htaccess greift aber früher.

...
Meine Variablen haben natürlich Namen, die dann per mail-Funktion weitergeschickt werden. Das jemand genau die Namen der Variablen "errät" und dann mein Script benutzt ist unwahrscheinlich oder?

Wie das bei flash/swf ist, weiss ich nicht. Bei einem normalen HTML Formular kann man die Variablen Namen (genauer die Namen der Input Felder) aus dem Quelltext herauslesen.
Wenn das Skript sicher ist, ist das aber kein wirkliches Problem (oder anderes herum, weil das so einfach ist, muss das Skript sicher sein).

Da fällt mir eben ein, es gibt doch in PHP eine Klassenbibliothek zum Versenden von Emails. Ich arbeite meist mit Perl, darum weiss ich den genauen Namen nicht mehr.

[edit]@moses
Das kann man nicht ausschließen, ist nach meinem Kenntnisstand aber nicht weit verbreitet.
Ganz sicherstellen kann man mW nie, dass der "Client" nicht das ist, was er scheint. Geschickt programmierte Roboter können alles imitieren, was normale Webclients auch machen würden.

 

[2nd]

Und was, wenn der Sender des Formulars auch den Referer fälscht?

Verstehe nur Bahnhof
So weit ich weiss, werden HTTP_REFERER doch nicht von allen Browsern übertragen oder?

Die Variablen sind nicht ohne Reverse Engeneering rauszufinden, das SWF müßte dekompiliert werden - zu umständlich.

Dann werde ich mal in dem Münz rumwühlen...

Frank

 

[maceis]

Verstehe nur Bahnhof
So weit ich weiss, werden HTTP_REFERER doch nicht von allen Browsern übertragen oder?
...

Wer sich nicht ans Protokoll hält, kann Dein Formular dann leider nicht benutzen.

 

[b.legt210]

Da werden sich die lieben IE Version6-Nutzer aber bedanken die verschicken nä(h)mlich keine REFERER-Angaben, schließlich nimmt M$ Sicherheit ja ernst und tut was dafür.
Wie auch immer. Ich würd das PHP-Skript mit einigen Tests ausstatten, so bist du (halbwegs) auf der sicheren Seite. Siehe dazu z.B. http://www.heise.de/ct/ftp/05/22/208/

Stephan

 

[2nd]

die verschicken nä(h)mlich keine REFERER-Angaben,

So was meinte ich. Dann sind 85% der Nutzer ausgeschlossen

Frank

 

[maceis]

Da werden sich die lieben IE Version6-Nutzer aber bedanken die verschicken nä(h)mlich keine REFERER-Angaben, schließlich nimmt M$ Sicherheit ja ernst und tut was dafür.
...

Und was bitte ist das?

HTTP_REFERER => http://perl.maceis.dom/test/bsp_1.html
HTTP_USER_AGENT => Mozilla/4.0 (compatible; [COLOR=blue]MSIE 6.0[/COLOR]; Windows NT 5.0)

Aber Du hast natürlich insofern Recht, dass man prüfen muss, ob man damit nicht jemand ungewollt aussperrt.

Was verstehst Du unter "halbwegs sichere Seite"?
Dass nur jeder zweite Angriff erfolgreich ist? (SCNR)

 

[b.legt210]

Mogeln gilt nicht !

Und was bitte ist das?

HTTP_REFERER => http://perl.maceis.dom/test/bsp_1.html
HTTP_USER_AGENT => [COLOR=Navy][SIZE=5]Mozilla/4.0[/SIZE][/COLOR] (compatible; [COLOR=blue]MSIE 6.0[/COLOR]; Windows NT 5.0)

gib also zu: du hast Mozilla mit IE-Kennung. Wie auch immer, Default bei IE6 ist kein Referer.

Was verstehst Du unter "halbwegs sichere Seite"?
Dass nur jeder zweite Angriff erfolgreich ist? (SCNR)

Damit meine ich, dass es genug andere, schlechter geschützte Formulare im Netz zu finden gibt. Ergo werden sich die Spammer diese suchen und das so geschützte links liegen lassen.
100%-igen Schutz gibt es nicht, außer natürlich bei Herrn Kaiser von der Hamburg Mannheimer (??).

Stephan

 

[maceis]

Das ist ein IE 6 unter W2k.
Warum da Mozilla steht? kA

 

[asylum]

was genau ist denn das fuer ein Script, das du schuetzen moechtest?
Einfach nen Kontaktformular?
Je nachdem wo fuer es ist kann man es auch ganz leicht loesen, was kein Robot selbst machen kann.
Habe bei meinen Gaestebuechern die vollgespammt worden sind einfach unten eine Textbox gemacht, in der die Loesung von 1+1 eingegeben werden musss.
Wenn die Eingabe nicht stimmt, dann wirds eben net gespeichert ...

sehr simpel, weiss jedoch nicht, ob es dir in deinem Fall hilft

 

[koli.bri]

Eine Kurze Zwischenfrage. Lässt sich der unerlaubte Zugriff nicht auch SO verhindern?

In der Aufrufenden Datei (bzw. in einer anderen Datei, die auf jeden Fall aufgerufen wird), wird eine Funktion erstellt, die einfach nur den wert TRUE zurückgibt.

function nohack(){
   return true;
}

In der Datei, die sich um die anderen Sachen kümmert, bzw, alle anderen Dateien, die aufgerufen werden beginnen dann folgendermaßen:

nohack() OR die("Ne, Alder, alleine mach ich gar nuechts!!!")

Wird die Datei alleine aufgerufen, so vermisst sie nicht nur die Funktion nohack, was nicht nur zu der ersten Fehlermeldung führen sollte, sondern sie bricht auch sofort ab, da der Befehl hinter dem "OR" ausgeführt wird.

Das wäre doch an und für sich einfacher. Und jemand, der sich PHP-Scripts wie Textdateien auslesen kann, ohne dass der Server sie verarbeitet, der kann sich doch auch htacces-Dateien auslesen.

(Und in Kombination wäre dass dann das sicherste, oder?)

Oder hab ich das jetzt total missverstanden?

 

[moses_78]

....Das wäre doch an und für sich einfacher. Und jemand, der sich PHP-Scripts wie Textdateien auslesen kann, ohne dass der Server sie verarbeitet, der kann sich doch auch htacces-Dateien auslesen....

Dir ist bewusst, dass man den Quelltext der PHP-Scripte bei normalfunktion
des Servers generell nicht sehen kann, oder? Und der Zugriff auf .htaccess
wird durch die Direktive "FilesMatch" unterbunden

 

[koli.bri]

Dir ist bewusst, dass man den Quelltext der PHP-Scripte bei normalfunktion
des Servers generell nicht sehen kann, oder? Und der Zugriff auf .htaccess
wird durch die Direktive "FilesMatch" unterbunden

Deshalb meinte ich ja, gegen jemanden, der DAS kann, hilt selbst .htacces nicht mehr.

 

[maceis]

...
Und der Zugriff auf .htaccess
wird durch die Direktive "FilesMatch" unterbunden

AFAIK ist das die Directive "Files"