ELEXPRESS.de |

Webmaster und Online Marketing Blog
etoro

PHP und MySQL Sicherheitsmaßnahmen

Es kommt auch heutzutage noch immer vor, dass viele eigen programmierte Webseiten in einem erhöhtem Sicherheitsrisiko existieren, da sich die Programmierer nicht ausreichend um die Sicherheit gekümmert haben. Die Folgen solcher Programmierung können verheerend hoch sein, daher möchte ich nun einige Sicherheitsmethoden vorstellen, wie man sich effektiv gegen die bekanntesten Angriffe schützen kann.

Die goldene Regel bei der sicheren PHP Programmierung ist:
Die Usereingaben sind gefährlich.

Schutz vor SQL-Injection

Angreifer versuchen mittels SQL-Injection eigen eingeschleuste MySQL Befehle auszuführen, um so eventuelle Werte der Datenbank zu ändern, manipulieren oder gar zu löschen.

Hier sollte darauf geachtet werden, dass der potentielle Angreifer keine Chance hat SQL Befehle einzuschleusen. Um hier für den ausreichenden Schutz zu sorgen sollte man gucken, ob die eingegebenen Datentypen stimmen und den Querystring vor der Datenbankverarbeitung escapen.

Schutz vor Cross-Site Scripting (XSS) Angriffen

XSS Angriffe werden meistens von Angreifern dazu eingesetzt Webseiteninhalte zu verändern oder Schadecode einzuschleusen. Meistens werden hier JavaScript Codes eingeschleust und dann von den einzelnen Clienten aufgerufen, wenn es nicht vorzeitig von der Serveranwendung abgefangen wurde. Dies kann etwa das Eingabeformular einer Webseite sein, wie in Webshops, Foren, Blogs und Wikis üblich.

Um also einen XSS Schutz einzubauen sollte man jede Usereingabe die später wieder ausgegeben wird auf unerwünschte Inhalte wie JavaScript prüfen.

  • strip_tags() — Entfernt HTML- und PHP-Tags aus einem String (Dazu unbedingt Beispiel 1# ansehen)

RFI/LFI Dateioffenlegung

LFI bedeutet “Local File Inclusion” und bezeichnet das Ausnutzen einer Lücke auf einer Internetseite, um somit Daten aufzurufen die lokal auf dem Webserver liegen.

RFI bedeutet “Remote File Inclusion” und bezeichnet das Ausnutzen einer Lücke auf einer Internetseite, in die man Code includiert, der nicht lokal auf dem Webserver abgespeichert ist, sondern überall anders liegen kann.

Um sich vor derartigen Angriffen zu schützen, sollte man alle Funktionen, die irgendwas mit dem Dateisystem zu tun haben (include, require, readfile, file_get_contents und viele mehr) genauestens überprüfen.

Ein Beispiel für einen PHP Code wo diese Angriffe angewandt werden können ist.


The End

Ich hoffe damit einigen helfen zu können Ihre Webseiten und Anwendungen sicherer zu gestalten. Über weiterführende Angriffsmöglichkeiten, die häufig vorkommen oder ergänzenden sicherheitsbringenden Funktionen freue ich mich natürlich ;) .


11 Kommentare »

mig

Öh ja, ein Beispiel ist? :P

Dominik

Hallo danke für den Hinweis es gab eine Komplikation mit einem Plugin. Das Beispiel sollte nun wieder zu sehen sein.

Auch wenn ich diese Lücken schon kannte, ist das eine sehr nützliche Übersicht, vorallem für Anfänger.

Simon

Dominik

Danke das denke ich auch leider werden diesen Artikel wohl zu wenig sehen.

Achwas, bei entsprechenden Suchbegriffen findet man dich sicher über Google.

Wie oft wurde der Artikel schon gelesen?

Dominik

Ja unter PHP Sicherheitsmaßnahmen rankt der Artikel gut. Aber zu PHP Sicherheit gibt es einfach zu harte Konkurenz und wer macht sich schon die Mühe ersteres Keyword einzugeben xD.

Gelesen wurde der Artikel laut Google Analytics ~60 Mal.

gute Verlinkung macht auch viel aus :)
Kannst ja in irgendwelchen PHP-Foren den Link zum Artikel posten. Natürlich nur, wenn er in entsprechende Threads passt

Danke für den Artikel, muss mich gerade gezwungenermaßen damit beschäftigen, habe in einem Video auf Yahoo (http://de.video.yahoo.com/watch/6376488/16537285) gesehen, dass der Autor dort die Funktion ctype_alnum() als Schutz vor XSS-Attacken benutzt. Ist das plausibel – oder besser noch strip_tags() mit rein? Und was ist mit der SafeSQL-Klasse von Monte Ohrt

Dominik

Hallo kogentis,
“gezwungenermaßen” < - hört sich aber nicht gerade begeistert an ;) .

htmlentities() <= XSS Schutz
mysql_real_escape_string() <= SQL Injection Schutz

Die SafeSQL Klasse kenne ich nicht.

Hallo Dominik,

danke für die Antwort. Das “gezwungenermaßen” eher, weil ich mal wieder an einer Webapp (die nicht erfolgreich attackiert wurde bisher) bastele. Da macht man sich lieber im Vorfeld gründlich Gedanken um die nötige und sinnvolle Sicherheit. Die Klasse SafeSQL ist leider seit 2007 nicht mehr aktualisiert worden. Dann werde ich wohl oder übel neu überlegen müssen und ein paar meiner älteren Klassen aktualisieren.

htmlentities()
reicht wohl alleine nicht mehr aus:

mysql_real_escape_string()
bereits umstritten:
http://das-computer-board.de/Schutz-vor-SQL-Injections-thread-176.html

.. in Zeiten automatisierter Attacken durch Toolsets wirds kritisch. 100%ige Sicherheit heisst heutzutage – Server herunterfahren ;-)

Dominik

Hi,
ich konnte bisher noch keine Lücken in meinen Anwendungen finden. Es mag schon sein, dass es niemals 100%igen Schutz auf Grund dieser Funktionen gibt.

Wenn Zeichen wie % usw nicht gebraucht werden, würde ich deren Eingabe einfach verbieten. Ansonsten sollte eine Webanwendung unter Nutzung der Funktionen schon ziemlich sicher sein ;) .