PHP sicher programmieren

[feuervogel]

okay, franzx, wir leben in der neuzeit, dann nenne mir einen spamschutz, Bedingungen: Öffentlich, zentral, dynamisch, für jeden Menschen einfach lösbar, für nen Bot nicht.

Man sollte darauf achten, dass die Felder aus dem Formular die im Mail-Header vorkommen nicht per bcc: o.ä. als spam-verteiler genutzt werden.

desweiteren können auch captchas geknackt werden. es wird von den botbetreibern eine seite mit begehrten inhalten eingerichtet, auf die man nur gelangt, wenn ein captcha gelöst wird. dieses captcha ist dann genau das, auf das der bot stößt wenn er es irgendwo anders lösen soll.

[meikel (†)]

Zitat von Franzx

Das sehe ich aber schon anders. Das ist doch eine reine Entwicklungsfrage.

Das kannst Du sehen, wie Du willst, aber das Problem ist nicht lösbar, wenn man auf Barrierefreiheit beharrt.

Entweder das Script müllt tonnenweise SPAM durch die Gegend oder man muß ein maschinenunlesbares Captcha abtippern.

Ohne dich persönlich anzugreifen, aber dieser Spruch ist doch sehr anmaßend und antiquiert.

Dein Ding. Versuche einfach mal, logisch zu denken. Es geht darum, zwischen Mensch und Maschine zu unterscheiden. Also gilt es, ein Verfahren zu verwenden, daß nicht maschinell gefälscht werden kann. So einfach ist das.

[HSchoepke]

Hallo,

das mit den Captchas sehe ich auch noch nicht als optimale Lösung bezogen auf Barrierefreiheit.

Bezogen auf barrierfreie Formulare kann man schauen was auf anderen Seiten gemacht wird:
- Zum einen gibt es Seiten auf denen als Alternative zum Bild auch ein akustisches Captcha angeboten wird. Hier gibt es aber Seiten auf denen ich den gesprochenen Code im Hintergrundgeräusch kaum verstehen kann.
- Alternativ kann man auch anbieten per Telefonanruf einen Freischaltcode abzurufen (ähnlich der Softwareaktivierung). So groß ist der Anteil der blinden User auch nicht, dass die Telefonanrufe zum Dauerproblem werden.
- Eine weitere Alternative ist, es dem User per Text mitzuteilen, welches von mehreren optionalen Checkmark-Feldern angekreuzt sein muss und welches nicht angewählt werden darf.
Beispiel: Wählen Sie alle Felder an, in denen zwei identische Zeichen hintereinander folgen. o hxs75dzsgr o lakcjddadte o kajld54w65
Hier könnte man verschiedene Anleitungstexte (Selbstlaute; eine Ziffer; der dritte Buchstabe des Alphabets; eine Zahl zwischen 55 und 70) per Zufall einbauen und abfragen.
- Mir fällt auch auf, dass Formulare, die sich über mehrere Seiten erstecken (kann auch nur bei mir so sein) bisher keine SPAM-eMails verursachen. Wenn man mit Session und einem auf dem Server abgelegten Code (hidden) - für jeden Seitenwechsel unterschiedlich generiert - das mehrstufige Formular durchläuft. Dann müsste ein Bot hier schon wirklich von Seite zu Seite springen, bis das Formular abgesendet wird. Noch weiter erschweren kann man den Massen-Versand, wenn zwischen den Seiten eine Zeitsperre die Auslieferung der Folgeseite um beispielsweise 20 Sekunden verzögert, natürlich nur nach vorherigem Hinweis an den User. Es versteht sich von selbst, dass solch ein Script nach erfolgtem Seitendurchlauf jeweils nur eine eMail oder was auch immer für einen Vorgang auslöst.

Sicher es gibt keine wirklich absolut sichere Variante um zu verhindern, dass diese Überprüfungsmechanismen automatisiert gelöst werden. So kann man aber zumindest schon automatische Scripts die alle Formularfelder ausfüllen abhalten. Wenn jemand es auf eine spezielle Seite abgesehen hat ist so zumindest ein wenig Aufwand nötig um einen angepassten Bot zu programmieren. Und genau wenn das passiert ist - und der SPAM überhand nimmt - ändert man den Schutzmechanismus, möglichst ohne Rückmeldung an den Bot zu liefern.


Feuervogel muß ich zustimmen bei:

Man sollte darauf achten, dass die Felder aus dem Formular die im Mail-Header vorkommen nicht per bcc: o.ä. als spam-verteiler genutzt werden.

Vielleicht kann man dem User auch Hinweis zum Ausfüllen eines bestimmten Text-Feldes geben (Bitte verwenden Sie einen aussagekräftigen, deutschsprachigen Betreff und beginnen Sie diesen mit drei Doppelkreuzen). Das verhindert zwar den SPAM nicht, erleichtert aber das Aussortieren der SPAM-eMails enorm.

Und ein Hinweis zu FranzX:

Das ist doch eine reine Entwicklungsfrage. Je mehr Leute sich daran setzen um eine Lösung zu finden um so schneller wird dies realisierbar sein.
Früher konnten Rollstuhlfahrer in keine Bus rein, heute werden die Busse, Strassenbahnen so gebaut. Es geht und es macht sich keiner mehr Gedanken darüber.
Wenn ich mir die Entwicklung im Automobilbau ansehe und den Fahrerleitsystemen so werden blinde Menschen bald ohne weiteres auch ans Steuer eines Autos können.

Hier könnte man das Problem SPAM als solches durch neu zu entwickelndes nicht berührungsloses (=sicheres) eMail-Protokoll ablösen bei dem der UserClient und der eMail-Server zuvor eine gesicherte Verbindung (ähnlich SSL) aushandeln. Sicher für einen Übergangszeitraum löst dies das Problem noch nicht, aber 5 1/4 oder 8 Zoll Floppys benutzt heute auch keine mehr. Und wenn alle Produzenten von eMail-Servern und -Clients sich dafür einsetzen, dann muss dies noch nicht mal so lange Dauern, wie die Umstellung auf IP6.
Immer dran denken: Wer sich nicht auf den Weg begibt kann auch nie ankommen.

Und wo wir grad bei SSL sind. Wenn die Formularseite auf einem echten SSL-Server liegt hat man zumindest gleich die IP-Adresse des SPAM-Versenders.
Für aufwendige begehrenswerte Funktionalitäten (Suchmaschinenanmeldung, Produktverkauf) hinter solch einem Formular lohnt sich bestimmt auch die Anschaffung eines passenden SSL-Zertifikats.

So genug Vorschläge von mir. Es wäre nett, wenn Ihr hier weitere Vorschläge macht.

Mit freundlichen Grüßen

Hartmut

[meikel (†)]

Zitat von HSchoepke

das mit den Captchas sehe ich auch noch nicht als optimale Lösung bezogen auf Barrierefreiheit.

Das ist völlig Wurscht, wie Du das siehst.

Solltest Du irgend wann mal eine Erleuchtung haben, wie man auf einem Wwebserver einen sehbehinderten User von einem SPAM-Bot-Script unterscheiden kann, kannste Dich ja mal melden.

Bezogen auf barrierfreie Formulare kann man schauen was auf anderen Seiten gemacht wird:
- Zum einen gibt es Seiten auf denen als Alternative zum Bild auch ein akustisches Captcha angeboten wird. Hier gibt es aber Seiten auf denen ich den gesprochenen Code im Hintergrundgeräusch kaum verstehen kann.
- Alternativ kann man auch anbieten per Telefonanruf einen Freischaltcode abzurufen (ähnlich der Softwareaktivierung). So groß ist der Anteil der blinden User auch nicht, dass die Telefonanrufe zum Dauerproblem werden.

Das kannste alles knicken.

Akkustik: "weil dann der nächste Einwand kommt: was ist mit den Seh- und Hörbehinderten?"

Freischaltcode per Teflon: sowas lassen wir lieber, bevor die Kumpels mit den 0900er Nummer noch auf dumme Gedanken kommen.

- Eine weitere Alternative ist, es dem User per Text mitzuteilen, welches von mehreren optionalen Checkmark-Feldern angekreuzt sein muss und welches nicht angewählt werden darf.
Beispiel: Wählen Sie alle Felder an, in denen zwei identische Zeichen hintereinander folgen. o hxs75dzsgr o lakcjddadte o kajld54w65
Hier könnte man verschiedene Anleitungstexte (Selbstlaute; eine Ziffer; der dritte Buchstabe des Alphabets; eine Zahl zwischen 55 und 70) per Zufall einbauen und abfragen.

Sowas macht ein Script mit links. Die Jungens schlafen doch nicht! Mit Reklame für die berühmte "SPAM"-Suppe wird Knete gemacht. Und wenn da ein paar interessante Webseiten auftauchen, die mit solchen Ratespielchen kommen, dann wird einer drangesetzt, der genau dafür ein Script programmiert.

Captcha ist "weiß-Gott" keine Alternative, aber geschickte Captchas verhindern momentan noch den Einsatz von OCR Software.

Bevor Du Dich aufregst: natürlich muß der User besser lesen können als das OCR-Script, aber er muß eh lesen können, falls es sich nicht um eine Website für Hörbücher handelt. Oder verlangst Du auch Barrierefreiheit für Radiosender? Es könnte ja auch ein Nichthörender mit Adleraugen vor dem Lautsprecher hocken...

[FabianWesner]

Hallo Balum82,

ich versuche mal das Thema Sicherheit ein wenig zu ordnen.

Auf ein Formular gibt es verschiedene Angriffsmöglichkeiten:

1. Parametermanipulation
2. XSS
3. Code-Injection
4. SQL-Injection
5. SPAM

Gegen Parametermanipulation kann man nicht viel machen. Egal ob mit Post oder Get gearbeitet wird. Den Daten vom Clienten darf man nicht trauen. Wenn man z.B. angibt, dass ein Inputfeld nur 10 Zeichen enthalten darf, kann der User das dennoch einfach umgehen. Daher muss alles was von den Usern kommt Serverseitig gecheckt werden. Man überlegt sich also für jedes Eingabefeld Regeln und prüft diese dann immer ab (z.B. min-Länge, max-Länge, nur Zahlen, ...).

XSS steht für das einschleusen von schadhaften Javascript oder HTML-Code. Entweder um anderen Usern per Parametermanipulation manipuilierte Links unterzuschieben oder um Javascript in die Datenbank zu speichern und so in sensible Bereiche vorzudringen. Man könnte z.B. Javascript in den HTTP-Header schreiben, welcher von vielen Counterprogrammen ungecheckt gespeichert wird. Schaut sich der Admin das dann später an, kann das Script z.B. dessen Cookies klauen, so dass ein Angreifer als Admin zugreifen kann.
Gegen XSS hilft zum einen der konsequente Einsatz von

htmlentities(strip_tags($userinput));

. Ausserdem sollte nur mit $_POST['input'] gearbeitet werden, um manipulierte Links (z.B. www.domain.de/id=<bösesscript>) zu verhindern. Wenn man HTML in den Formularen erlauben, aber XSS verhindern will wird es sehr schwierig. Das sollte man sich vorher genau überlegen.

Mit Code-Injection wird versucht PHP-Code einzusetzten. Wird z.B. ein include($inputvariable); benutzt, dann wird in $inputvariable enthaltener Code ausgeführt. Der Angreifer kann dann nach herzenslust zugreifen. Das verhindert man automatisch mit strip_tags().

Bei SQL-Injection versucht der Angreifer SQL-Statements einzubringen. Damit kann man viel Schaden anrichten und Passwortanfragen einfach umgehen, z.B. durch eingabe von "xxx OR 1 = 1" im Passwortfeld. Das OR wird als SQL-Statement ausgeführt und liefert natürlich TRUE zurück. Dagegen schützt man sich, indem man erstmal viele böse Substrings (INSERT, DELETE, WHERE, ...) ausfiltert. Danach wird es schwieriger... man kann Leerzeichen filtern, aber eine richtig gute Lösung kenn ich noch nicht.

SPAM in Formularen ist ärgerlich. Captchas helfen, sperren aber die Blinden aus. Meiner Meinung muss jeder selbst wissen ob er Rücksicht nehmen will und SPAM manuell aussortiert oder eben nicht. Auf einer kommerziellen oder privaten Seite würde ich CAPTCHAs einsetzen. Es gibt einfach zu wenig blinde Menschen als das sich der Aufwand lohnt. Barrierefreiheit ist nur für staatliche Webseiten vorgeschrieben. Natürlich kann ein Angreifer Captchas aushebeln, aber man hält sich dennoch 90% der Spammer vom Hals. Eine bessere Methode gibt es soweit ich weiss noch nicht.

Zitat von Heinrich

"Christopher Kunz - Peter Prochaska: PHP-Sicherheit (dpunkt.verlag) - kostet halt schlappe 36 Euro. Die Jungs scheinen aber echt Profis zu sein - zu PHP und MySQL.

Das Buch ist sehr empfehlenswert. Es ist für PHP-Entwickler und nicht für Serveradmins geschrieben. Es ist relativ leichte Kost und man kann es in wenigen Stunden lesen. Meine Aufzählung oben kann als grobe Zusammenfassung des Buches angesehen werden.