Prepared Statements und zusätzliches Filtern

[css_chaos]

Hallo,
ich hab mal eine kurze Frage: Genügt es eigentlich seine Webanwendung mit Prepared Statements zu schützen, oder sollte man die eingegebenen Daten der User vorher noch zusätzlich filtern? Denn eigentlich wird bei Prepared Statements durch das getrennte senden von Statement und Parametern schon jede Art von SQL-Injection verhindert, oder?

 

[B3nnoX]

Also vor SQL Injection solltest du mit Prepared Statements eigentlich geschützt sein, aber ich denke da wird dir der Sicherheitsexperte @nookie dir was dazu sagen können

Und bzgl. noch mehr Filterungen, ich bin immer der Meinungen das sowas nie verkehrt ist. Also wenn ein User nur eine Zahl eingeben darf, dann darf er auch nur eine Zahl eingeben. Bzw. wenn er in einem Feld kein HTML eingeben darf, dann darf er das auch nicht. Ich gebe dem User denn auch die Meldung das unzulässige Zeichen verwendet wurden sind etc.

Deswegen bin ich der Meinung das sowas nie schaden kann. Und von welcher Art von Filterung sprichst du?

 

[css_chaos]

Mit Filterung meine ich, dass z. B. mit htmlentities(); Sonderzeichen in Entities umgewandelt werden und dass schon vor der Eingabe in die Datenbank. Schadhafte Parameter (wenn das bei Prepared Statements überhaupt noch möglich wäre) wären so zu 100 % ungefährlich. So hätte man auch schon die XSS-Angriffe abgewehrt, was man sonst eigentlich erst bei der Ausgabe macht.

Wenn der User eine falsche E-Mail Adresse, Zahl oder ähnliches eingibt (wenn Zahl oder E-Mail Adresse gefordert sind), soll er, wie du sagst, eine Meldung erhalten, dass das nicht geht.

 

[nookie]

Also vor SQL Injection solltest du mit Prepared Statements eigentlich geschützt sein, aber ich denke da wird dir der Sicherheitsexperte @nookie dir was dazu sagen können

Wat für Sicherheitsexperte?

Mit Filterung meine ich, dass z. B. mit htmlentities(); Sonderzeichen in Entities umgewandelt werden und dass schon vor der Eingabe in die Datenbank. Schadhafte Parameter (wenn das bei Prepared Statements überhaupt noch möglich wäre) wären so zu 100 % ungefährlich. So hätte man auch schon die XSS-Angriffe abgewehrt, was man sonst eigentlich erst bei der Ausgabe macht.

Wenn der User eine falsche E-Mail Adresse, Zahl oder ähnliches eingibt (wenn Zahl oder E-Mail Adresse gefordert sind), soll er, wie du sagst, eine Meldung erhalten, dass das nicht geht.

Benutze anstatt htmlentities() lieber htmlspecialchars(). Zum Thema Prepared Statements, bist du eigentlich auf der sicheren Seite aber gibt ja noch zählige andere Angriffs-Möglichkeiten außer Cross-Site Scripting und SQL-Injection.

 

[scbawik]

Also eigentlich ist es ja egal ob du HTML/Javascript in die Datenbank speicherst.
Der Datenbank tut das nichts. Du musst sie nur vor SQL schützen.

Erst direkt bei der Ausgabe im Web-Browser ist das escapen von HTML wichtig.
Nur so kannst du sicher sein, dass auf keinen Fall (HTML-)Code injiziert werden kann.

Es könnte bspw. jemand Zugang zu deiner DB erlangen und direkt HTML-Code hineinschreiben.
In diesem Fall würde dein Schutz nicht mehr greifen.

Oder jemand (oder du) erweitert dein INSERT-Script und vergisst dabei nur einmal HTML zu escapen -> Wieder wäre XSS möglich, da du ja blind davon ausgehst dass die Daten in der DB sauber sind.

Außerdem benötigen zB JSON oder andere Computerprogramme als ein Webbrowser kein escaptes HTML, da dort ja auch kein HTML interpretiert wird. Wenn du die Daten also mal nicht im Webbrowser anzeigen möchtest, wird dir der escapte Code aus der DB angezeigt und du müsstest ihn wieder zurückwandeln um auf die eigentliche Eingabe zu kommen.

 

[css_chaos]

Danke für eure Hilfe. :) Ich werde folgendes machen: Wenn bei einer Eingabe vom User ein bestimmtes Format wie eine Zahl, E-Mail, Telfonnummer, usw. gefordert ist, wird sie validiert und bei Bedarf dem User eine Fehlermeldung zurückgegeben. Sind alle Daten so wie sie sein sollten, werden sie einfach der Datenbank mit Prepared Statements zugeführt (wobei in der ganzen Anwendung nur Prepared Statements verwendet werden). Daten die aus der Datenbank abgefragt wurden, werden, kurz bevor sie dem User ausgegeben werden noch von gefährlichem Code befreit.
Bei andere Angriffsmöglichkeiten habe ich schon so gut ich konnte vorgesorgt.

 

[nookie]

Danke für eure Hilfe. :) Ich werde folgendes machen: Wenn bei einer Eingabe vom User ein bestimmtes Format wie eine Zahl, E-Mail, Telfonnummer, usw. gefordert ist, wird sie validiert und bei Bedarf dem User eine Fehlermeldung zurückgegeben. Sind alle Daten so wie sie sein sollten, werden sie einfach der Datenbank mit Prepared Statements zugeführt (wobei in der ganzen Anwendung nur Prepared Statements verwendet werden). Daten die aus der Datenbank abgefragt wurden, werden, kurz bevor sie dem User ausgegeben werden noch von gefährlichem Code befreit.
Bei andere Angriffsmöglichkeiten habe ich schon so gut ich konnte vorgesorgt.

Welche anderen sind dir denn bekannt?

 

[css_chaos]

Ich kenne noch:
CSRF, Session-Highjacking, Brute-Force Attacken, Lauschangriffe, Angriffe auf das Dateisystem, Remote Code Execution, Mail-Injection und den "Man in the Middle". Ich glaube das sind die wichtigsten, sollte ich welche vergessen haben, ergänze sie bitte noch.

 

[nookie]

Ich kenne noch:
CSRF, Session-Highjacking, Brute-Force Attacken, Lauschangriffe, Angriffe auf das Dateisystem, Remote Code Execution, Mail-Injection und den "Man in the Middle". Ich glaube das sind die wichtigsten, sollte ich welche vergessen haben, ergänze sie bitte noch.

• Local File Inclusion
• Command Injection
• Blind SQL-Injection
• Denial of Service
• Server-Side Includes Injection
• Direct Dynamic Code Evaluation
• Path Traversal
• Full Path Disclosure
• Comment Injection Attack
• Cross Frame Scripting

 

[css_chaos]

Stimmt die gibts auch noch alle. Danke für die Ergänzung. Das mit den Server Side Includes kannte ich noch gar nicht. Ich hab etwas recherchiert und bin drauf gekommen, dass man die Injection von SSI verhindern kann, indem den User Input validiert oder filtert.

Ich bin mit den SSI Injections (und der SSI Technik im allgemeinen), wie schon gesagt, noch nicht ganz vertraut und wollte noch kurz fragen, ob man diese auch kurz vor dem Output noch herausfiltern kann, falls der Input erst in eine Datenbank gespeichert wird und dann erst ausgegeben wird, denn ich hab auch gelesen, dass es möglich ist PHP Code in einer SHTML Datei ausführen zu lassen.

 

[sysop]

Benutze anstatt htmlentities() lieber htmlspecialchars(). .....

Ich will sicher nicht streiten, aber das stimmt so nicht.

An und für sich sind htmlentities() und htmlspecialchars() komplett identisch, nur wandelt htmlentities() tatsächlich ALLE Zeichen um, denen ein HTML-Zeichen zugeordnet werden kann. htmlspechialchars() setzt voraus, dass die Eingabe-Kodierung identisch zur Ausgabekodierung festgelegt ist.

Ich formuliere es mal lapidar so, dass htmlentities() seine Funktion immer ausführt und somit der "sicherere" Weg ist.

....Es könnte bspw. jemand Zugang zu deiner DB erlangen und direkt HTML-Code hineinschreiben.

Dann ist ohnedies schon Hopfen und Malz verloren und jeder Schutz, auch der vor SQL-Injections hat schon versagt.

 

[scbawik]

Dann ist ohnedies schon Hopfen und Malz verloren und jeder Schutz, auch der vor SQL-Injections hat schon versagt.

Nicht wirklich. Bei einem Cracker natürlich schon.
Wer es aber darauf abgesehen hat, unbemerkt Passwörter abzugreifen oder anderes kann dies mit reinem DB Zugang dann trotzdem nicht tun - Stichwort Schadensbegrenzung.
Der Zugriff muss außerdem nicht über SQL Injections erfolgen, sondern kann auch aus fehlerhafter Serverkonfiguration und/oder reiner Schlampigkeit entstehen.

Ich will sicher nicht streiten, aber das stimmt so nicht.

An und für sich sind htmlentities() und htmlspecialchars() komplett identisch, nur wandelt htmlentities() tatsächlich ALLE Zeichen um, denen ein HTML-Zeichen zugeordnet werden kann. htmlspechialchars() setzt voraus, dass die Eingabe-Kodierung identisch zur Ausgabekodierung festgelegt ist.

Ich formuliere es mal lapidar so, dass htmlentities() seine Funktion immer ausführt und somit der "sicherere" Weg ist.

htmlspecialchars wandelt alle relevanten Zeichen um. Der Rest ist einfach nicht relevant.
Deshalb ist htmlspecialchars zur genüge sicher.

Bei beiden muss jedoch auch auf den zweiten Parameter geachtet werden, da standardmäßig keine einzelnen Anführungszeichen umgewandelt werden.

 

[sysop]

htmlspecialchars wandelt alle relevanten Zeichen um. Der Rest ist einfach nicht relevant.
Deshalb ist htmlspecialchars zur genüge sicher.
.....

Ich betone nochmal, ich möchte da keine Grundsatzdebatte führen, ich gehe davon aus, dass man sich schlau macht, wann man was verwendet.

Ich habe nur schon einige interessante Blüten gesehen, wo auf einem Windows-Server (natürlich ISO kodiert) durch eine falsche Verwendung von default_charset() zum Teil recht heftige Unterschiede zwischen den beiden Funktionen heraus kamen. Wenn ich mich recht entsinne verwendet PHP 5 seit Version 5.3 oder 5.4 als default Charset (wenn nicht anders angegeben) utf8. Bei beiden Funktionen sollte also (sofern möglich) die zu verwendende Kodierung angeben werden.

Man stelle sich folgendes lustiges Szenario vor:
Auf einem Windows-Server sei die Eingabe per default iso kodiert, per default in php5 setzt htmlspecialchars utf8 zur Kodierung ein und das ganze wird dann wegen eines Programmfehlers ohne header ausgegben.
ein utf8_encode($str) vor der Verwendung von htmlspecialchars() oder htmlentities() kann da auch nicht schaden.

Für wen Sicherheit oberste Priorität hat, der sei der Vollständigkeit halber noch auf http://us1.php.net/manual/de/function.mb-encode-numericentity.php verwiesen.