Posts tagged php

Sicherheit mit PHP

Vorkenntnisse

Quellen im Internet

php.net Sicherheitshinweise
Sicherheitsweise direkt von der Community von PHP.
Besonders auf die Nullbyte Problematik sollte man achten.

http://www.cms-sicherheit.de/
Über diese Webseite kann man sich einen guten Überblick verschaffen über die Sicherheitsthematik in PHP. Mit vielen weiterführenden Links zu den einzelnen Themen kann man sich so informieren, wie man PHP am sichersten Programmieren kann. Ich will in diesem Beitrag auf Sicherheitsthemen eingehen, die weniger dokumentiert sind.

Allgemein

Fremde Inhalte und Datenschutz

Es ist nicht sonderlich zu empfehlen seine Webseite auf fremden Inhalten aufzubauen in denen diese von den entsprechenden Servern geladen werden. Zum einen könnte der Server ausfallen und die Webseite würde nicht mehr funktionieren, man könnte die Dateien auch manipulieren und so aus einer CSS-Datei einen Angriff auf Ihre Benutzer starten. Zum Anderen ist dieses vorgehen meiner Meinung nach auch Datenschutzrechtlich bedenklich, denn der Server von dem die Dateien geladen werden erhält Informationen über die Benutzung Ihrer Webseite, besser gesagt über Ihre Benutzer. Sie sind auf jeden Fall auf der sicheren Seite wenn Sie fremde Inhalte selbst hosten. Das geht natürlich nicht immer. Ein Youtube-Video z.B. kann nicht einfach selbst gehostet werden. Zum einen sind Videos ein sehr resourcenhungriger Aspekt in der Datenübertragung und zum Anderen hat man nicht die Rechte zur Veröffentlichung. Man sollte es dann aber zumindest so lösen, dass Youtube z.B. nicht automatisch geladen wird sondern erst wenn der Benutzer es ausdrücklich wünscht, das macht Ihre Webseite zudem schneller und zeigt, dass Ihnen die Anliegen Ihrer Benutzer am Herzen liegen. JQuery und Google Fonts einfach selbst hosten. Auf Google-Analytics verzichten und stattdessen selbst z.B. PIWIK hosten. In Zeiten der Sensibilisierung für Datenschutz und nicht zuletzt wegen der Abmahnungsgefahr ist dies auf jeden Fall der sichere Weg.
Während das Laden von Fremdinhalten für technische Angriffe auf der einen Seite genutzt werden kann ist es auf der anderen Seite die Sicherheit die man dem Benutzer gibt wenn er Ihre Seite besucht.

Klientseitig

CSS, expression() und url()

Mit expression(…) oder url(…) kann man beliebigen JavaScript Code ausführen. Auch hier gilt, keine fremden Inhalte laden. Diese können beabsichtigt oder unbeabsichtigt kompromitiert werden.

Schema bei Links prüfen

Wenn man Links von Benutzern eintragen lässt, dann sollte man diese gegen eine Liste erlaubter Schema validieren. Andernfalls kann es sein, dass jemand „javascript:window.location=’bad.de'“ als URL übermittelt. Im href-Attribut des a-Tags wird das dann natürlich ausgeführt. Selbes gilt auch für das src-Attribut im img-Tag. Ich denke die meisten die einen solchen Dienst anbieten gehen im Höchstfall davon aus vielleicht mal einen FTP-Link zu veröffentlichen, demnach sollte die Validierung gegen eine Whitelist meistens möglich sein. Auch das automatische vorransetzen von http:// ist hierbei denkbar, das würde JavaScript auch entschärfen. Über parse_url() bekommt man Informationen zum übermittelten Schema.

Serverseitig

Weiterleitungen validieren

Man sollte bei Redirects darauf achten, dass keine ungewollten URLs ausgeführt werden können. Dabei könnte ein Angreifer einem Benutzer einen Link übermitteln der dem Anschein nach von Ihrem Angebot stammt und auf die Seite eines Angreifers weitergeleitet werden. Für Phishing sehr interessant da Phishing-Filter oft darauf zurückgreifen, gefakte URLs zu analysieren. Für interne Weiterleitungen sollte man darauf achten eine relative Adresse zuzulassen, dadurch kann niemand nach außen weiterleiten.

SQL-Injection auf umwegen

Vielleicht hat ein Angreifer eine Stelle in Ihrem Programmcode gefunden in dem Sie den String unmaskiert verwenden obwohl Sie darauf bereits geachtet haben. Es könnte sein, dass Sie die SQL-Injection in Ihrer Datenbank steht und Sie diesen String später aber als vermeindlich sicher einschätzen.

Der Wert kommt aus der Datenbank aber das heißt nicht, dass man die Injection nicht doch über PHP auslösen kann obwohl man vorher mit mysql_real_escape_string() darauf geachtet hat.

Vorsicht mit Bildern

Bilder niemals direkt mit include() einfügen. Es kann passieren, dass entweder ein Bild mit der Erweiterung .php hochgeladen wurde oder Bilder sogar vom Parser ausgeführt werden. Bilder können nämlich beliebigen Programmcode enthalten. Auch bei JavaScript darauf achten, dass Bilder für Angriffe verwendet werden können.