Archive for the ‘Sicherheit’ tag
Manipulationen erkennen – Bemerken dass man gehackt wurde
In viele Webseiten wird heutzutage eingebrochen und es werden Änderungen an der Webseite durchgeführt. Das kann die selbst programmierte Webseite sein bei der man eine Lücke eingebaut hat, das kann aber auch ein installiertes WordPress oder Joomla sein.
Häufig sind solche Angriffe nicht geziehlt, sondern werden mittels automatischer Scripte durchgeführt, die dann auf allen anfälligen Servern kleine Änderungen an den Dateien durchführen:
– Phishing Webseiten werden auf den Server gelegt
– in die Webseite wird bösartiger Code eingebaut der mittels Flash, Javascript, Windows Media Player oder anderen Techniken versucht einen Drive-By-Download bei den Besuchern zu platzieren
– die Webseite wird „nur“ defaced, sprich ein witziges Bild wird auf die Webseite gesetzt die den Besitzer blossstellen soll
– an strategisch gut platzierte Stellen im Code werden mail() Aufrufe eingefügt die beispielsweise die Klartextpasswörter an den Angreifer senden
– es werden kleine Scripte abgelegt wie beispielsweise PHProxy oder ein Spam-Mail-Script
– heutzutage wird auch gern die .htaccess Datei verändert, mit der der Suchmachinen-Traffic auf eine andere Seite umgeleitet wird, beispielsweise so:
Dieser Schlüssel zerstört sich in 30 Sekunden selbst
Gastartikel von Oliver Sperke.
Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängigsten Internetsprachen: PHP, HTML, Javascript und CSS.
Nachdem ich ja in den letzten Wochen über den sicheren Umgang mit Passwörtern in Webprojekten erzählt habe, soll es heute mal um etwas anderes gehen (aber trotzdem um das Thema Sicherheit). Wenn man oft auf fremden oder eigenen Servern arbeitet, kommt man an OpenSSH eigentlich nicht vorbei. Und wenn man dazu noch so faul ist wie ich (und vermutlich die meisten von Euch auch), hat man keine dutzenden Dateien mit Passwörtern, sondern wickelt die gesamten Loginvorgänge mit Hilfe von öffentlichen und privaten Schlüsseln ab. Dieses Verfahren ist nicht nur bequem, es bietet auch zusätzliche Sicherheit, da man nicht in Versuchung kommt, einfache Passwörter zu verwenden. Ausserdem ist die eigene Passwortliste schon von Haus aus verschlüsselt.
Das Verfahren hat aber für einen Serverbetreiber Nachteile. Der öffentliche Schlüssel muss auf dem Server hinterlegt werden. Ausserdem muss man sobald der Zugang nicht mehr benötigt wird, nachsehen, ob ein Benutzer sich vielleicht eigene Schlüssel hinterlegt hat und natürlich muss man ihm den Zugang manuell sperren.
Passwort Blacklist
Kunden, die eine Webseite mit Registrierung und Login benötigen kann man nicht immer davon überzeugen, strenge Passwortrichtlinien anzusetzen. Wenn ich vorschlage „10 Zeichen, davon mindestens eine Zahl, ein Großbuchstabe und ein Sonderzeichen“ wird das nicht selten abgelehnt, mit Hinweisen auf „Dann sinkt die Conversion-Rate“, „Dann vergessen die Kunden andauernd ihr Passwort und wir haben mehr Supportaufwand“ etc. Also kommt häufig die Richtlinie „mindestens 8 Zeichen“ zum Einsatz.
Damit ich mich darauf einlasse verlange ich aber mindestens eine Passwort Blacklist, sprich eine Liste der meistgenutzten Passwörter, die dann nicht erlaubt sind, beispielsweise „12345678“ oder „passwort“, um das ganze zumindestens etwas sicherer zu machen. Man muss den Benutzer vor sich selbst schützen, sonst werden sie „12345678“ oder „passwort“ als Passwort nutzen.
Schöner hashen mit bcrypt
Gastartikel von Oliver Sperke.
Ich bin 34 Jahre alt und seit 10 Jahren selbständiger Webentwickler. Mein Fokus liegt dabei auf der Erstellung, Beratung und Optimierung in den Bereichen High Performance, Usability und Sicherheit in den gängisten Internetsprachen: PHP, HTML, Javascript und CSS.
Bei meinem vorherigem Gastbeitrag wurde ich direkt im ersten Kommentar aus meiner heilen Welt geworfen. Dort stand nämlich folgender „erschütternder Kommentar“ zu lesen:
Das du Salting und Mehrfachhashing predigst, während der Rest der Welt schon einen Schritt weiter zu bcrypt geht… Traurig.
Nun ja, dazu möchte ich drei Dinge sagen.
- Ich predige nicht (Ausnahme: „Es heißt Standard, verdammt, nicht Standart!“).
- Ach, wenn die Welt schon mal auf dem Stand des einfachen md5 wäre …
- Bcrypt verdient einen eigenen Beitrag.
Natürlich hatte der Autor völlig recht. Über Hashfunktionen im Web zu schreiben und bcrypt nicht zu erwähnen ist fast schon schändlich. Also bcrypt ist eine Hashfunktion, die auf Langsamkeit optimiert wurde. Um genauer zu sein, es ist nicht mal ein richtiger Hashalgorithmus, sondern eine Blowfish Verschlüsselung, bei der am Ende „die Schlüssel weggeworfen werden“, daher lässt sich das Ergebnis nicht mehr entschlüsseln. bcrypt ist eine Weiterentwicklung der „Traditional DES Scheme“ Funktion aus der Unixwelt. Obwohl dieses Verfahren 30 Jahre lang (!) gute Dienste geleistet hat, stellen sich so langsam „Alterserscheinungen“ ein. Der Zahn der Zeit nagt auch hier in Form von gestiegener Rechenleistung.
Kurze Rückschau
create_function() genauso übel wie eval()?
Heute mal eine Sonntagsfrage:
Ich überlege gerade wie ich ein Problem löse, bei dem ich wohl nur mit viel Aufwand drumherum komme, eval() zu benutzen. Auf der Suche nach einer Lösung fiel mir auch die Funktion create_function() ein, der man ähnlich wie eval() einen String übergeben kann, der dann beim Aufruf der erstellten Funktion ausgeführt wird.
Und nun meine Frage an euch: Sind die beiden Funktionen in der Gefährlichkeit gleichzusetzen wenn man beide mit einem String füllt, der zusammengesetzt wurde aus Usereingaben? Bei beiden kann böses passieren wenn man die Usereingaben nicht ordentlich filtert, sehe ich doch richtig oder? Seht ihr einen Vor- oder Nachteil von create_function() gegenüber eval()?
Ich frage weil eval() überall auf der Welt als böse angesehen wird, aber über create_function() redet niemand, und ich glaube bei unvorsichtiger Nutzung ist sie genauso gefährlich.
