Archive for the ‘Sicherheit’ tag
2-Faktor-Authentifizierung mit dem Google Authenticator
Viele größere Webdienste bieten mittlerweile die 2-Faktor-Authentifizierung an, PayPal, Amazon, Facebook und nicht zuletzt Google. Mit der 2-Faktor-Authentifizierung muss neben dem Benutzernamen und Passwort auch noch ein Einmal-Passwort, ein sogenanntes One-Time-Token eingegeben werden, das von einem Gerät unabhängig vom PC generiert wird und nur einmal gültig ist. Sollte es also jemand schaffen und das Passwort erraten oder mitschneiden, hilft es dem Angreifer wenig denn er muss auch noch Zugriff auf das Hardwaregerät bekommen, und das sollte schwierig sein.
Die Generierung von solchen Codes ist nicht sonderlich schwer, beide Parteien (das Gerät und die Webseite) müssen nur ein gemeinsames „shared secret“ kennen (auch Seed genannt), und aufbauend auf diesem dann sich immer ändernde Codes generieren können. Dazu gibt es RFCs, beispielsweise RFC 4226.
Client-Zertifikate als sicherer Login-Ersatz?
Wer auf Sicherheit achtet und seinen Webseitenbesuchern etwas Privatsphäre spendieren möchte installiert ein SSL-Zertifikat auf dem eigenen Webserver. Damit ist es Besuchern möglich verschlüsselt mit dem Webserver zu kommunizieren und ein eventuell vorhandener Mithörer im offenen WLAN guckt dumm aus der Wäsche. Spätestens wenn es um Login-Daten oder andere persönliche Informationen geht sollte HTTPS eigentlich mittlerweile Standard sein, aber auch für normale Seiten lohnt es sich, denn bereits eine URL verrät einiges über eine Person, auch wenn die Seite eigentlich nichts geheimes enthält.
HashDoS Angriff legt (unter anderem) PHP lahm
Ich bin leider die letzten 2 Tage nur wenige Stunden dazu gekommen die Live-Streams vom 28. Chaos Communication Congress (28C3) zu schauen, aber bzgl. PHP ist heute Nachmittag ein interessanter Talk gehalten worden mit dem Thema Effective Denial of Service attacks against web application platforms dem ich hier einen kurzen Artikel widmen werde.
Es geht darum wie PHP (und die anderen anfälligen Sprachen auch) Hash-Tabellen erstellen und verwalten. Die hier interessante Hash-Tabelle ist das $_POST Array, das man von außen füllen kann, und das anfällig ist wenn man nur genügend „passende“ Datensätze reinfüllt. Der Algorithmus der die Hash-Tabelle befüllt wird nämlich langsamer sobald Kollisionen der Keys auftreten. Schickt man also beispielsweise 300KB POST-Daten an ein PHP-Script ist eine schnelle CPU damit ca. 30 Sekunden unter Volllast. Bei 8MB (dem Standard-Maximum für POST-Daten in der php.ini) wären es immerhin schon 5 Stunden, die die CPU benötigt um die Hash-Table zu füllen. Man kann also mit einer relativ kleinen DSL-Leitung einigen Schaden anrichten. Mit einer Gigabit-Leitung kann man so 10.000 CPU-Kerne dauerhaft beschäftigen.
Die Reporting-Funktion der Content-Security-Policy (CSP)
CSP hatte ich vor fast 2 Jahren bereits vorgestellt, mittlerweile hat es eine gute Verbreitung gefunden, sodass wir uns nochmals die Details anschauen. CSP ist ein Header, den der Server an den Browser schickt, und darin festlegt, von wo Javascripte, Bilder, CSS, Media-Dateien und mehr geladen werden dürfen. Mit sinnvollen Einstellungen ist es möglich, Cross Site Scripting (XSS) sowie Clickjacking zu verhindern, eine dieser essenziell wichtigen Einstellungen ist das Verbot von Inline-Javascript. Falls also ein Angreifer Javascript beispielsweise in die Datenbank einfügen kann, und bei der Ausgabe nicht oder falsch escaped wird, wird das Inline-Javascript das der Angreifer platziert hat nicht ausgeführt, XSS ist effektiv unterbunden.
In der Apache Konfiguration kann das beispielsweise so aussehen:
<VirtualHost *:80>
DocumentRoot /path/to/wwwroot
ServerName domain.de
Header add X-Content-Security-Policy "allow 'self'; img-src images.domain.de; script-src static.domain.de;"
</VirtualHost>
oder hier mittels PHP gesetzt:
<?php
header("X-Content-Security-Policy: allow 'self'; img-src images.domain.de; script-src static.domain.de;");
Sollten nun Bilder oder Javascripte eingebunden sein die nicht von den angegebenen Domains kommen wird der Browser sie blockieren und nicht laden. Es gibt neben img-src und script-src auch noch frame-src, xhr-src und weitere.
Das Problem mit HEAD Requests in PHP
Ich bin gerade auf ein interessantes Verhalten gestoßen das eventuell große Probleme bereiten kann. Wahrscheinlich nur sehr wenige von euch werden das hier wissen, trotzdem ist es sehr interessant und provoziert eventuell Probleme und Sicherheitslücken.
Das hier vorgestellte Verhalten ist wahrscheinlich kein Problem von PHP sondern eventuell vom Webserver, aber ich weiß es nicht genau. Vielleicht kann ja mal jemand mit Tomcat oder nginx dieses Problem nachstellen.
Wir nehmen folgendes Script als Beispiel:
<?php
file_put_contents('/tmp/outp', '1');
echo 'start';
file_put_contents('/tmp/outp', '2', FILE_APPEND);
echo 'ende';
Ich glaube ihr stimmt mir alle zu wenn ich behaupte: Das Script erstellt immer eine Datei mit dem Inhalt „12“. Es kann zum Beispiel nicht passieren dass nur „1“ in der Datei steht.
