wie Sicherheit eines Scriptes erhöhen

[Sven Rautenberg]

Moin!

1. Leerzeichen am Anfang und am Ende entfernen (trim())

Immer.

Warum? Das ist nichts, was irgendeine Sicherheit erhöht, das ist ausschließlich dazu da, "schöne" Strings zu haben - wobei "schön" eben definiert ist als "keine Leerzeichen drumherum". Andere Schönheitsideale führen zu anderen Anforderungen (beispielsweise: Postleitzahlen bestehen nur aus Ziffern - was in Deutschland funktioniert, international aber Probleme machen wird).

2. Falls die URI der Homepage ohne führendes "http://" eingegeben wurde, wird selbiges vor die URI eingefügt. Sollte man die angegebene URI auf Erreichbarkeit prüfen?

Würde ich so machen.

Würde ich nicht so machen. Also die Prüfung, ob die URI erreichbar ist. Kostet nur Zeit, verursacht Traffic und ist nichtssagend. Letzt war über einen Tag (warum auch immer) eine meiner Domains nicht erreichbar, weil der Server platt war. Dürfte ich dann nicht die Domain eintragen, nur weil der Schaden nicht sofort behoben war?

3. HTML-Tags entfernen (strip_tags())
   Auf jeden Fall. Evntl. am Ende die Zeilenumbrüche beibehalten...

HTML-Tags _nicht zulassen_ wäre die bessere Alternative. Aber dann doch bitte nicht mit dieser überaus _dummen_ Funktion strip_tags(). Die ist nämlich so strohdumm, die löscht aus dem String alles raus, was zwischen den Zeichen "<" und ">" steht - auch wenn dazwischen absolut kein HTML-Tag steht.

Besser: Die Zeichen "<", ">" und "&" in Entities umwandeln mit htmlspecialchars(). Dann kann man diese Zeichen (und beispielsweise auch HTML-Quellcode) ins Gästebuch eintragen, ohne dass sie als HTML wirksam werden.

Als Gimmick kann man BB-Code anbieten. Christian Seiler hat dafür eine nette Klasse geschrieben: http://www.christian-seiler.de/projekte/php/bbcode/

4. Über die IP-Adresse wird ein erneutes Absetzen eines Eintrages (F5-Taste im IE oder Absicht) für einen frei definierbaren Zeitraum gesperrt (derzeit 300 Sekunden) - wenn zwei Benutzer die hinter ein und denselben Proxy sitzen posten wollen, habe ich natürlich ein Problem - kennt einer eine bessere Lösung? Session-Handling fände ich fast übertrieben und ist doch auch durch "Browser schließen, Browser öffnen" zu umgehen, oder?

Was auch geht: Nach dem Submit das Script verlassen und auf eine Antwortseite umleiten - da kann jeder F5 drücken wie er will.

Wer Gästebücher fluten will, der wird nicht F5 drücken, sondern ein Skript einsetzen, was das für ihn übernimmt.

Die Weiterleitung auf eine Antwortseite ist aber dennoch gut, weil unabsichtliches Neuladen vermieden wird. Also unbedingt machen.

Sessions bringen hier keine Abhilfe gegen böse Skripte, denn die eröffnen einfach pro Request eine neue Session. Und wenn es notwendig ist, zuerst die Formularseite abzurufen, damit in der Session die Postingfähigkeit freigeschaltet wird, werden sie auch dies tun. Bringt also kein Mehr an Sicherheit, nervt nur die Benutzer und ist aufwendig herzustellen.

Weiterhin gebe ggf. ich zum Blättern zwei Parameter in der URL mit (start und limit in der SQL-Query), sollten diese manipuliert werden, kann dann etas außer einer evtl. ungültigen Abfrage Passieren?

Aufpassen, wie diese Parameter dann in den SQL-Query gelangen. Du mußt sicherstellen, dass nur die Zahlenparameter weiterkommen, aber keinerlei Text. Eine gute Idee wäre, intern eine Konstante "Postings pro Seite" zu haben und extern nur die fortlaufende Seitennummer aufzurufen (1, 2, 3,...), welche intern dann in entsprechende LIMIT-Parameter umgesetzt werden.

Ich mach das immer so:
jeder Parameter like ?new=1 wird über eine Kontrollstruktur (if -elsif)abgefragt. Am Ende dieser Kontrollstruktur steht ein else "Parameter nicht erlaubt" o.ä.

Was spricht gegen Ignorieren? Ist ja nun kein großer Unterschied, ob ein Parameter mit einer Fehlermeldung bedacht wird, oder ob er in so einem Fall einfach unwirksam ist. Ist zumindest für den Angreifer dann nicht sofort ersichtlich, weil er trotzdem eine nette Seite erhält.

- Sven Rautenberg