Skripte und Datenbanken absichern

Mich würde einmal interessieren, mit welchen Methoden ihr Eure PHP-Scripts und MySQL-Datenbanken schützt. Dabei meine ich beispielsweise SQL-Injections oder Session-Hijacking. Was unternehmt ihr dagegen? Was gegen andere Sicherheitslücken? Oder kurz: Wie sichert ihr Euer Browsergame ab?

erstmal Hauptmotto was jeder kenne sollte: "Daten die vom User kommen SIND IMMER Böse"
zu MySQL Injections: NIEMALS egal wo auch immer der wert herkommt daten einfach so in nen query schreiben - IMMER mysql(i)_real_escape_string nutzen
auch bei jeder anderne datenbank die jeweiligen escape funktionen nutzen
Zu XSS alles was dem User angezeigt wird und von einem User kommt am besten immer durch htmlentities jagen
Session Hijacking - 1. Massnahme keine Session IDs in die URL - der User kopiert gerne URLs - 2. evtl alle x Anfragen/Minuten ein session_regenerate_id
ansonten gehe ich immer persönlich so ran als ob ich das system cracken will und schaue wo ich alles weiter komme und evtl fehler erzeuge oder sonstiges

Gut zum Thema Sicherheit sind auch die Tipps auf php.net besonders die Kommentare, dort werden anschaulich die Maßnahmen um MySQL-Injection, Session-Hijacking, unsichere, per Get und POST übertragene Variablen, ... zu vermeiden.
Viele Grüße
birne

Ich bin soweit gegangen, das alle Variablen, die von aussen kommen, registriert sein müssen und durch ein Skript zumindest darauf geprüft werden, ob der Typ stimmt (bzw. in diesen Typ gewandelt werden). Strings kommen immer durch mysql(i)_real_escape_string (allerdings nur, wenn keine magic_quotes aktiv sind).
Damit fühle ich mich recht sicher.

Wer gerne das Thema in Buchform aufbereitet haben möchte,
ich finde das Buch "PHP Sicherheit" (ISBN-10: 3898643697 ) sehr gut gelungen.
Aber, mit etwas gutem Willen und Fleiß findet man diese Infos auch im Web.

Sicherheit in einem etwas anderem Teilbereich behandelt www.w3.org/2001/tag/doc/whenToUseGet.html
Dabei geht es zum Beispiel darum, dass man destruktive Funktionen nicht in GET-Aufrufen zulässt. Wer schonmal ein Problem damit hatte, weiß, dass auch das etwas mit Sicherheit zu tun hat.

Interessant für alle PHP Entwickler sollte dies hier sein: www.cback.de/cback_software/standalonect.php
Ich nutze es seit geraumer Zeit ohne Probleme, das Scripr kann leicht an eigene bedürfnisse angepasst werden und schützt wunderbar vor Wurm attacken sowie vor sql-injectionen
gruß
Korporal

Schwachsinniges Script, sorry.
1. Man muss einen Hinweis auf das Script im Footer platzieren. Ein um so willkommenerer Hinweis für den geneigten Cracker da ihm hiermit signalisiert wird: der Programmierer hat null Ahnung von Sicherheit und vertraut auf schwachsinnige Scripts die
2. keinen Schutz gewähren. Das Script macht nur einen Abgleich mit einer Liste von Strings die bei einem Angriff in der URL auftauchen könnten. Wie z.b. "select " oder "/etc/passwd". Da gibts nur zwei Probleme:
a) Die Teststrings stehen in Kleinschreibug in der Liste, str_replace (was zum Testen verwendet wird) achtet aber auf Groß-/Kleinschreibung, ich muss also nur "Select " statt "select" schreiben und das tolle Tool funktioniert schon nicht mehr. Jetzt kann der Programmierer natürlich superschlau sein und (ab PHP 5) str_ireplace nehmen.
b) Man kann den kompletten "Angriffsstring" mit %XX Kodierungen schreiben. Und schon wieder ist das Tool aufgeschmissen. Jetzt könnte man natürlich wiederrum den Filter erweitern, dass er das auch noch erkennt. Aber dann lässt sich der geneigte Angreifer eben was neues einfallen. Die Funktionsweise des Scripts ist bekannt, die Suchliste auch.
3. dem Angreifer mitteilen, was er falsch gemacht hat. Schlaue Idee ...
Langer Rede kurzer Sinn: kümmer dich lieber um Sicherheit anstatt nutzlose Tools einzusetzen die es dem Angreifer eher erleichtern als erschweren.

Original von KuMbA
Der Hinweis ist sicher sehr nervig und einen Schutz der über den reinen Abgleich des Strings hinaus geht bietet es auch nicht aber ich sehe dabei zwei Sachen.
1. Ein Angreifer der auf Teufel komm raus eine Lücke finden will wird sie finden.

Das mag sein. Sicherheitslücken können sich immer einschleichen. Man muss es einem Angreifer aber auch nicht erleichtern
Wenn du einen Schutz einführst der keiner ist bist du dir vielleicht bewusst, dass er nicht besonders effektiv ist. Du bist dir aber auch bewusst, dass du etwas einführst was "ja schon irgendwie ein Schutz sein wird" - und wirst später erst recht nachlässiger.

2. Kann man weniger begabte Angreifer mit diesem Script schon einmal abfangen. (Ich denke hier an die Typen die ein Tutorial auf dubiosen Seiten lesen und es dann einfach mal testen)

Ein weniger begabter Angreifer würde wohl schon alleine daran scheitern, dass er es erst gar nicht schafft kompromitierbare Eingaben zu identifizieren. Und ich würde mich da auch nicht darauf verlassen. Vielleicht hälst du dir damit tatsächlich ein paar Lamer vom Leibe, eine wirkliche Bedrohung wären die aber sowieso nicht solange man sich nicht ausschliesslich auf so ein Tool lässt.

Mein Fazit:

Das Tool bietet im Grunde einen guten Ansatz (wenn man die Erkennung selbst und evtl. noch etwas verbessert das Array erweitert) aber es darf und kann nur die erste einer Reihe von Sicherheitsstufen sein.
Nein, es bietet einen völlig falschen Ansatz.
1. Mit statischem Patternmatching (selbst wenn du das Script noch mit regulären Ausdrücken und haste-nicht-gesehen aufbohrst) bist du dem Angreifer immer hinterher. Denn du schliesst nur Lücken die entweder so simpel sind, dass man sie mit einfachen Mustern abbilden kann oder die bereits stattgefunden haben, von denen du also weisst mit welchen Mustern du prüfen musst um sie nicht nochmal zu ermöglichen. Ein schwacher Trost ...
2. Es wiegt dich in einer falschen Sicherheit, da es im Grunde nur dem Angreifer nutzt.
3. Man sollte nicht auf vorgeschaltete "Sicherheitsstufen" vertrauen sondern erst gar keine Angriffsmöglichkeiten in dem Code hinter den Sicherheitsstufen aufmachen. Und wenn dein Code vernünftig ist brauchst du auch keine Scripts von diesem Schlag mehr.

naja in php5 kann man ja dann gleich ext/filter[1] nutzen
und wenn man noch mehr zeit hat evtl mal mit Chorizo[2] durch sein Game durchgehen. Desweiteren gibts ja noch den Hardened PHP Patch[3] und die Suhosin Extension[4], die letzen beiden sachen sollte man nur als übergangslösung sehen, den sie sind eher dafür gedacht unsichere apps etwas abzusichern.
1. a) pecl.php.net/filter
1. b) www.php.net/filter
2. [URL]https://chorizo-scanner.com/[/URL]
3. www.hardened-php.net/hardening_patch.14.html
4. www.hardened-php.net/suhosin/index.html

Original von KuMbA
1. Ein Angreifer der auf Teufel komm raus eine Lücke finden will wird sie finden.

Je komplexer die Software ist, desto schneller schleichen sich Fehler ein. Aber solche trivialen Dinge wie SQL Injections kann man inzwischen sicher unterbinden. mysql_real_escape_string() & Co sind schon eine ganze Weile veraltet und nebenbei auch etwas stümperhaft.
Hat man eine gewisse Erfahrung erreicht schreibt man ohne prepared Statements keine Datenbankanbindungen mehr
Spart ne Menge Arbeit und macht SQL Injections aller Art ungültig (Stichwort PDO)

Original von KuMbA

2. Kann man weniger begabte Angreifer mit diesem Script schon einmal abfangen. (Ich denke hier an die Typen die ein Tutorial auf dubiosen Seiten lesen und es dann einfach mal testen)
Damit fängst du alle unter 12 Jahren ab, das stimmt wohl. Aber die 13 jährigen die das Hexadezimalsystem verstehen und 0x2F in Dezimal umrechnen können hörts dann schon wieder auf.
Alleine die Idee sämtliche Abfragen mittels PHP zu durchleuchten ist sehr stümperhaft. Über die Rechenzeit die dafür drauf geht müssen wir nicht reden...
Dafür gibts den Apachen, mod_security und mod_evasive noch dazu um gleich simples BruteForce zu unterbinden.

Original von KuMbA

Das Tool bietet im Grunde einen guten Ansatz (wenn man die Erkennung selbst und evtl. noch etwas verbessert das Array erweitert) aber es darf und kann nur die erste einer Reihe von Sicherheitsstufen sein.
Naja...je nachdem welchen Anspruch du hast
Nein, mal im Ernst:
PHP ist allgemein sehr sicherheitskritisch und bei gerinem Unwissen tuen sich Löcher groß wie Scheunentore auf (sage nicht nur ich, sondern das kommt auch vom ehemaligen Chef des Security Response Teams Stefan Esser selbst ). Daher sollte eigentlich - gerade bei Nicht-Breufs-Informatikern - kein Webserver ohne Suhosin laufen.
Sei froh wenn du solche Checks anderen überlassen kannst und PHP weniger Arbeit hat.

Ich habe mir früher nie sorgen um Sicherheit gemacht, aber seit dem Artikel über XSS in der C't habe ich mir mal Gedanken dazu gemacht.
Und jetzt die Frage:
Reicht es wenn ich eine Sicherheitsfunktion schreibe der die zu überprüfende Variable und die max. länge übergeben wird.
diese Funktion soll dann alle Sonderzeichen ersetzten oder sowas in der art. Dann soll überprüft werden ob die Variable zu lang ist, wenn ja wird "Erro" zurückgegeben, ist die Variable nicht zu lang, dann wird die überarbeitete variable ausgegeben. Alle GET und POST Variablen werden durch die Funktion gejagt.
Reicht da um gegen Hack versuche gewappnet zu sein?
MfG Kevka

Bzgl des cback-Tools: Es ist Schwachfug. Sowas schlechtes habe ich lang nicht mehr gesehen.
> Reicht es wenn ich eine Sicherheitsfunktion schreibe der die zu überprüfende Variable und die max. länge übergeben wird.
Natürlich nicht. Du musst untersuchen ob die zu überprüfenden Variablen illegale Zeichen enthalten. Da ist die Länge ziemlich egal.
> Ein Angreifer der auf Teufel komm raus eine Lücke finden will wird sie finden.
Nein. Wenn man seine Programme ordentlich abkapselt und eine gewisse Sorgfalt walten lässt, kann man garantieren, dass sein Programm frei von Sicherheitslücken ist. Das hört sich hochgestochen an, aber bei all meinen Programmen bin ich mir verdammt sicher, dass sie keine Sicherheitslücke enthalten, die irgendwie zu einer Datenveränderung führen können.

wieso selbst schreiben? sowas gibt es doch zuhauf ..
du willst nen int?
$int = intval($_GET['int']); (falls das nen string, array, weisdergeierwas war wirds ne 0 oder 1 *klick*)
fließkommazahl?
$float = floatval($_GET['float']); (*klick*)
du hast ne db und angst vor SQL-injections?
$pdo->quote($_GET['bla']); *klick*
resp.
mysql_real_escape_string(...); *klick*
wobei die beiden letzten funktionen nur für strings genutzt werden sollten.. für zahlen hattan wir ja oben schon welche.
wenn man bestimmte formate haben will, kann man das mit regExes prüfen.
auf dämlichkeiten wie include($_GET['...']); geh ich jetzt nicht mehr ein ..
gegen XSS im speziellen hilft z.b. mit nem regex auf ne url (oder einen teil) zu prüfen (weil den angreifer will ja was externes aufrufen).
Generell eröffnest DU immer die möglichkeit zu einem xss. Wenn du z.B. ein in deinem html-code hast, wobei des ... aus der db kommt, dann musst du dafür sorgen, dass verdammtnochmal niemand etwas in die db schreiben darf, was annähernd so ausschaut wie eine externe datei .. oder man gleicht das mit eine whitelist ab, oder ...
du musst einfach nur merken: an welchen stellen füge ich dynamisch code ein (js == code)? die stellen musst du primär sicher machen. includes statisch halten (durch switches, ..), aber auch o.g. dyn. einbinden von js-code (über den man den gesamten dom-baum umstellen kann und somit auch externe inhalte auf client-ebene dynamisch einbunden kann.) können erhebliche sicherheitslücken entstehen.
gefährlicher ist sicher das xss auf php-ebene (/etc/passwd auslesen etc), aber auch auf client-ebene (js) kann man viel scheisse bauen und z.b. viren, trojaner, dialer o.ä. über deine seite verbreiten (die der ie6 bereitwillig installiert .. )
REMEMBER: ALL (and i really fuck*ng mean ALL) INCOMING DATA IS EVIL.
so... sollte nen kurzer anriss des themas sein und bei der problemlösung helfen.

Original von Drezil
flieskommazahl?
$float = intval($_GET['float']); (*klick*)

Wäre das dann nicht eher

$float = floatval($_GET['float']);

Nein. Wenn man seine Programme ordentlich abkapselt und eine gewisse Sorgfalt walten lässt, kann man garantieren, dass sein Programm frei von Sicherheitslücken ist. Das hört sich hochgestochen an, aber bei all meinen Programmen bin ich mir verdammt sicher, dass sie keine Sicherheitslücke enthalten, die irgendwie zu einer Datenveränderung führen können.

Das soll n Witz sein, oder? Keine Anwendung die mehr tut als "Hallo Welt" auszugeben, hat Sicherheitslücken. Die Frage ist nur: Wie schwer sind die zu entdecken, lohnt sich der Aufwand oder kann man da zufällig drüberstolpern?

Ich denke mal man kann seine Seite leicht insoweit absichern, dass die üblichen Tricks nicht funktionieren (XSS, SQL-Injection, ...). Für die, die die Mitteln/Wissen haben dürfte aber sowas natürlich nicht so leicht aufhalten. Da spielt aber auch die Servereinstellung und vieles mehr eine Rolle, nicht nur die PHP-Seite.

TheUndeadable hat schon recht insofern, als das sich viele der Standardszenarien grundsätzlich unterbinden lassen. SQL-Injections werden unmöglich wenn man
a) nur prepared Statements verwendet
b) die Statementstrings nicht dynamisch aus Eingaben zusammen baut oder dies nur mit Whitelists macht. D.h. statt

$sql = 'SELECT * FROM foo ORDER BY bar '.$_GET['sortorder'];

macht man

if($_GET['sortorder'] == 'asc') {

$sql = 'SELECT * FROM foo ORDER BY bar ASC';
} else {
$sql = 'SELECT * FROM foo ORDER BY bar DESC';
}
Das gleiche gilt um z.B. Includes anhand von Benutzereingaben abzusichern. XSS auf Clientseite lässt sich effektiv unterbinden, wenn die Templateengine Strings grundsätzlich nicht unentschärft durchleitet, d.h. ohne das man da extra überall htmlentities() oder ein Konstrukt der Templateengine hinsetzen muss.
Das sind aber auch wirklich nur Standardszenarios gegen die man sich recht einfach und effektiv wappnen kann. Aber es gibt auch viel kreativere Möglichkeiten eine Anwendung zu exploiten. Man könnte selbst wenn SQL-Injections verhindert werden eventuell trotzdem noch NULLs in die Datenbank einschleusen und damit die Scripts die das nicht erwarten zuverlässig zum Absturz bringen. Ein anderes Thema sind die Prüfung von Wertebereichen. Wenn ich eine Möglichkeit biete die Flottengeschwindigkeit von 10-100% zu regulieren, die Scripts es aber nicht merken wenn da einer 1000% eingibt kann man diese Lücke ausnutzen um effizient andere Spieler zu schrotten
Das sind dann IMHO die eigentlich wichtigen Szenarien. Kinderkram wie XSS und SQL-Injections lässt sich ziemlich effizient unterbinden.

an dem chorizo-scanner hab ich grad ne stunde verschwendet.. hat jede menge "vulnerabilties" gefunden, wo sein bestes ergebnis eigentlich das php-easteregg vom logo war ~.~
achja, er hat gefährliche vulnerabilities gefunden.
z.b. hat er vor meinen identifikationskey und vor meinem text onmouseover-strings hingeschrieben. hab dann den ganzen spam aus meinem (auch selbstgeschriebenem) forum löschen können.. ^^
sein bestes resultat war das er mich ausgeloggt hat. naja, soviel dazu.

TheUndeadable hat schon recht insofern, als das sich viele der Standardszenarien grundsätzlich unterbinden lassen.

Da geb ich recht, aber Fehlerfreiheit würde ich nie garantieren.
Robustheit kann man garantieren, den Ausschluss von Fehlern bei absichtlicher oder unabsichtlicher Falschbedienung kann man nicht garantieren.
Man kann alles tun, um solche Fehler zu verhindern, aber irgendwas wird man doch vergessen.

Ok, ich konkretisiere meine Aussage:
Ich könnte bei meinen Projekten eine Sicherheit bzgl der Einfallslöcher Stack Overflow, Heap Overflow und Injections aller Art garantieren. Es besteht allerdings immer das Problem logischer Sicherheitslöcher. Habe auch nicht von der Unmöglichkeit einer Datenlöschung, sondern von einer nahezu vorhandenen Unmöglichkeit einer nichtprivilegierten Datenveränderung gesprochen.
Ein Schritt dazu ist, dass ich genau weiß welche Klassen auf die Datenbank direkt zugreifen dürfen und welche Klassen SQL-Queries zusammenbauen. Fremde Komponenten dürfen dies nicht, sie dürfen nur diese Klassen nutzen. So kann man besonderen Augenmerk auf die sicherheitsrelevanten Klassen legen.

Original von woodworker
naja in php5 kann man ja dann gleich ext/filter[1] nutzen
und wenn man noch mehr zeit hat evtl mal mit Chorizo[2] durch sein Game durchgehen. Desweiteren gibts ja noch den Hardened PHP Patch[3] und die Suhosin Extension[4], die letzen beiden sachen sollte man nur als übergangslösung sehen, den sie sind eher dafür gedacht unsichere apps etwas abzusichern.
1. a) pecl.php.net/filter
1. b) www.php.net/filter
2. [URL]https://chorizo-scanner.com/[/URL]
3. www.hardened-php.net/hardening_patch.14.html
4. www.hardened-php.net/suhosin/index.html

hier noch ein paar links zum Thema Security:

http://phpsec.org/projects/
href="http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/" target=_blank>
und" target="_blank">http://www.sitepoint.com/blogs/2004/03/03/notes-on-php-session-security/
und für alle die denken dass captcha 100% sicher sind:
http://sam.zoy.org/pwntcha/