... newer stories
Donnerstag, 17. August 2006
[Thema: Datenschutz]
Der Heise Newsticker berichtet heute, dass in einem Gutachten für den Bundestag zur Umsetzbarkeit der TK-Vorratsdatenspeicherung diese stark angezweifelt wird. Bei Heise heisst es:
Die in der Richtlinie vorgesehene verdachtsunabhängige Aufzeichnung von Namen und Anschrift jedes Kommunikationspartners werde in diesem Hinblick größere Probleme auf als eine "schlichte Speicherung der Telefonnummer ohne direkte Rückführungsmöglichkeit zum Betroffenen".
Das ist wieder so eine merkwürdige Rechtslage - hier wird unterschieden zwischen Personendaten und Daten, die Personen nur zugeordnet werden können. Allerdings scheint mir hier die Zuordnung viel zu einfach zu sein, als dass sie eine Hürde darstellen würde für jemand, der diese Daten unbefugt in die Hände bekommt.
Schließlich kann man Telefonnummern im Normalfall inzwischen mit Inverssuche zu Namen auflösen, zum Beispiel auf Telefonbuch.de. Einzig die direkte Suche nach Namen in den gespeicherten Daten ist nicht möglich, bevor man diese Auflösung nicht vorgenommen hat, und wenn jemand eine Geheimnummer hat, kann man seinen Namen nicht mit den öffentlich zugänglichen Methoden auflösen.
Die in der Richtlinie vorgesehene verdachtsunabhängige Aufzeichnung von Namen und Anschrift jedes Kommunikationspartners werde in diesem Hinblick größere Probleme auf als eine "schlichte Speicherung der Telefonnummer ohne direkte Rückführungsmöglichkeit zum Betroffenen".
Das ist wieder so eine merkwürdige Rechtslage - hier wird unterschieden zwischen Personendaten und Daten, die Personen nur zugeordnet werden können. Allerdings scheint mir hier die Zuordnung viel zu einfach zu sein, als dass sie eine Hürde darstellen würde für jemand, der diese Daten unbefugt in die Hände bekommt.
Schließlich kann man Telefonnummern im Normalfall inzwischen mit Inverssuche zu Namen auflösen, zum Beispiel auf Telefonbuch.de. Einzig die direkte Suche nach Namen in den gespeicherten Daten ist nicht möglich, bevor man diese Auflösung nicht vorgenommen hat, und wenn jemand eine Geheimnummer hat, kann man seinen Namen nicht mit den öffentlich zugänglichen Methoden auflösen.
Dienstag, 15. August 2006
[Thema: augenblick-fingerfertig.de]
Hier gibt es einen Artikel zum Cross Site Scripting als Ausgangspunkt für Shell Access auf einem Webserver: XSS Vulnerability.
In diesem Artikel beschreibt der Autor, ein Seth Fogie drei Angriffsschritte zum Knacken einer Web Applikation:
Am Spannensten war für mich die Code Injection. Fogie hat anstelle eines Bildes ein PHP-Script (mit Endung .php) hochgeladen. Dieses wurde so abgelegt, dass es als Webseite aufrufbar war. Eine Prüfung auf eine Bild-Endung geschah nicht. Dadurch konnte er beliebigen Code in den Server einspielen und mit den Rechten des Webserver-Benutzers ausführen.
Diese Attacke ist bei OS Commerce nur im Admin-Bereich möglich: Dort wird z.B. für die Produktbilder beim hochladen keine Prüfung durchgeführt, ob es sich um eine Bild-Endung (.jpg, .jpeg, .png, .gif) handelt. Allerdings können im Admin-Bereich auch beliebige PHP-Dateien mit einem Editor verändert werden. Damit kann man ganz offiziell PHP-Code bearbeiten. Anders gesagt: Wer in den Admin-Bereich von OS Commerce eindrigen kann, kann auch seinen eigenen Code ausführen lassen. Um diesen Bereich abzusichern, müsste man den dortigen Datei-Manager entfernen und bei allen Aufrufen der "upload"-Klasse den Dateityp prüfen. Die Upload-Klasse bietet bereits eine Prüfung an, diese wird lediglich nicht genutzt: Der letzte Parameter beim Konstruktor upload() ist ein Array von erlaubten Endungen.
Kann man nun in den Admin-Bereich über Session Hijacking eindringen? Benutzer werden dort nicht wie im eigentlichen Webshop über Cookies oder Session IDs identifiziert. Stattdessen muss der Admin-Bereich über eine HTTP-Authentifizierungsmethode des Webservers gesichert werden. Dies kann man auf dem Apachen mit .htaccess Dateien oder über die Konfiguration des Webservers erreichen. Der im obigen Artikel beschriebene Session Hijacking Angriff greift damit für den Admin-Bereich nicht.
Kann nun das Session Hijacking im normalen Webshop (also nicht im Admin-Bereich) benutzt werden, um Benutzer-Sessions zu kapern und damit die Benutzerdaten (z.B. auch Kontodaten beim Lastschrift-Einzug) auszuspähen? Hierzu müsste ein normaler Benutzer (anonym oder als nicht-admin Benutzer angemeldet) Javascript-Code in die Webseiten des Shops einfügen können. Hier habe ich einige Stichproben durchgeführt:
Bei der Eingabe eines vorhandenen Benutzernamens werden weder der Benutzername noch das Passwort bei Falscheingabe in der nachfolgenden Fehlermeldung ausgegeben. Auch bei der Suche wird die Suchanfrage nicht in der Webseite angezeigt. Bei der Abgabe von Bewertungen werden < und > im vom Benutzer eingegebenen Text entfernt. So ergibt die Eingabe von
Insgesamt kann man keine dieser Eingabemöglichkeiten benutzen, um eine Cross Site Scripting Attacke durchzuführen.
Dies ist noch keine umfassende Überprüfung, langt mir aber für eine erste Einschätzung des OS Commerce: Herr Ponce De Leon scheint beim Bau des OS Commerce Systems auch an derartige Attacken gedacht zu haben, das ist recht beruhigend.
Achja, den zweiten Punkt, die Parameter-Veränderung habe ich nicht betrachtet. Das wäre aber ein grober Faux-Pas bei der Programmierung, und so etwas ist mir bei OS Commerce bisher nicht aufgefallen.
Meine Empfehlung zur Absicherung des Webshops: Man sollte den Admin-Bereich extrem stark absichern. Wenn man bedenkt, dass bei der BASIC HTTP-Authentifizierung das Passwort bei jedem Zugriff im Klartext übertragen wird, sollte man mindestens eine gesicherte Verbindung über HTTPS verwenden.
In diesem Artikel beschreibt der Autor, ein Seth Fogie drei Angriffsschritte zum Knacken einer Web Applikation:
- Session Hijacking, um die Session eines Benutzers mitbenutzen zu können, ohne sein Passwort eingegeben zu haben.
- Parameter-Veränderung um an Daten anderer Benutzer zu gelangen.
- Code Injection in den Server über einen File-Upload.
Am Spannensten war für mich die Code Injection. Fogie hat anstelle eines Bildes ein PHP-Script (mit Endung .php) hochgeladen. Dieses wurde so abgelegt, dass es als Webseite aufrufbar war. Eine Prüfung auf eine Bild-Endung geschah nicht. Dadurch konnte er beliebigen Code in den Server einspielen und mit den Rechten des Webserver-Benutzers ausführen.
Diese Attacke ist bei OS Commerce nur im Admin-Bereich möglich: Dort wird z.B. für die Produktbilder beim hochladen keine Prüfung durchgeführt, ob es sich um eine Bild-Endung (.jpg, .jpeg, .png, .gif) handelt. Allerdings können im Admin-Bereich auch beliebige PHP-Dateien mit einem Editor verändert werden. Damit kann man ganz offiziell PHP-Code bearbeiten. Anders gesagt: Wer in den Admin-Bereich von OS Commerce eindrigen kann, kann auch seinen eigenen Code ausführen lassen. Um diesen Bereich abzusichern, müsste man den dortigen Datei-Manager entfernen und bei allen Aufrufen der "upload"-Klasse den Dateityp prüfen. Die Upload-Klasse bietet bereits eine Prüfung an, diese wird lediglich nicht genutzt: Der letzte Parameter beim Konstruktor upload() ist ein Array von erlaubten Endungen.
Kann man nun in den Admin-Bereich über Session Hijacking eindringen? Benutzer werden dort nicht wie im eigentlichen Webshop über Cookies oder Session IDs identifiziert. Stattdessen muss der Admin-Bereich über eine HTTP-Authentifizierungsmethode des Webservers gesichert werden. Dies kann man auf dem Apachen mit .htaccess Dateien oder über die Konfiguration des Webservers erreichen. Der im obigen Artikel beschriebene Session Hijacking Angriff greift damit für den Admin-Bereich nicht.
Kann nun das Session Hijacking im normalen Webshop (also nicht im Admin-Bereich) benutzt werden, um Benutzer-Sessions zu kapern und damit die Benutzerdaten (z.B. auch Kontodaten beim Lastschrift-Einzug) auszuspähen? Hierzu müsste ein normaler Benutzer (anonym oder als nicht-admin Benutzer angemeldet) Javascript-Code in die Webseiten des Shops einfügen können. Hier habe ich einige Stichproben durchgeführt:
Bei der Eingabe eines vorhandenen Benutzernamens werden weder der Benutzername noch das Passwort bei Falscheingabe in der nachfolgenden Fehlermeldung ausgegeben. Auch bei der Suche wird die Suchanfrage nicht in der Webseite angezeigt. Bei der Abgabe von Bewertungen werden < und > im vom Benutzer eingegebenen Text entfernt. So ergibt die Eingabe von
<a href="http://www.tagesschau.de" onmouseover="alert('hacked!');">Tolle Seite</a>
nach dem Speichern den Text _a href="http://www.tagesschau.de" onmouseover="alert('hacked!');"_Tolle Seite..
Insgesamt kann man keine dieser Eingabemöglichkeiten benutzen, um eine Cross Site Scripting Attacke durchzuführen.
Dies ist noch keine umfassende Überprüfung, langt mir aber für eine erste Einschätzung des OS Commerce: Herr Ponce De Leon scheint beim Bau des OS Commerce Systems auch an derartige Attacken gedacht zu haben, das ist recht beruhigend.
Achja, den zweiten Punkt, die Parameter-Veränderung habe ich nicht betrachtet. Das wäre aber ein grober Faux-Pas bei der Programmierung, und so etwas ist mir bei OS Commerce bisher nicht aufgefallen.
Meine Empfehlung zur Absicherung des Webshops: Man sollte den Admin-Bereich extrem stark absichern. Wenn man bedenkt, dass bei der BASIC HTTP-Authentifizierung das Passwort bei jedem Zugriff im Klartext übertragen wird, sollte man mindestens eine gesicherte Verbindung über HTTPS verwenden.
Sonntag, 13. August 2006
[Thema: Weblogs]
In letzter Zeit sammle ich meine Bookmarks mit dem selbstgebastelten Tool, das ich "Quicklinks" getauft habe.
Dort poste ich wesentlich öfter Links als hier Blog-Beiträge, weil es viel schneller geht.
Die neuesten Quicklinks kann man hier oben rechts auf der Seite sehen. Dort sind auch die vollständigen Ansichten "Bookmarks nach Alter" und "Bookmarks nach Kategorie" verknüpft.
Seit eben gibt es auch eine RSS-Ansicht dieser Quicklinks. Sie ist bei "Bookmarks nach Alter" als RSS eingebunden. Der direkte link zum RSS heisst http://preiselbeersahne.no-ip.org/bookmarks/?style=rss. Man kann sich auch einzelne Kategorien als Feeds holen, dazu muss man den Kategorienamen urlencoded anhängen. Für die Kategorie "Web 2.0" sieht das z.B. so aus: http://preiselbeersahne.no-ip.org/bookmarks/?style=rss&kategorie=Web+2.0.
Nur falls jemand sowas mag :)
Dort poste ich wesentlich öfter Links als hier Blog-Beiträge, weil es viel schneller geht.
Die neuesten Quicklinks kann man hier oben rechts auf der Seite sehen. Dort sind auch die vollständigen Ansichten "Bookmarks nach Alter" und "Bookmarks nach Kategorie" verknüpft.
Seit eben gibt es auch eine RSS-Ansicht dieser Quicklinks. Sie ist bei "Bookmarks nach Alter" als RSS eingebunden. Der direkte link zum RSS heisst http://preiselbeersahne.no-ip.org/bookmarks/?style=rss. Man kann sich auch einzelne Kategorien als Feeds holen, dazu muss man den Kategorienamen urlencoded anhängen. Für die Kategorie "Web 2.0" sieht das z.B. so aus: http://preiselbeersahne.no-ip.org/bookmarks/?style=rss&kategorie=Web+2.0.
Nur falls jemand sowas mag :)
Freitag, 11. August 2006
[Thema: MetaPodcast]
Spreeblick-Podcast vom 9.8.2006
Holgi hat mal wieder angerufen... diesmal hat er sich erklären lassen wie man Uran anreichert. Nur falls man das mal selbst machen will :)
Donnerstag, 10. August 2006
[Thema: Musik]
Dienstag, 8. August 2006
[Thema: _kein_]
...alle Störfälle in deutschen Atomkraftwerken sind beherrschbar.
(Ein Pressesprecher von Vattenfall, eben im Morgenmagazin)
(Ein Pressesprecher von Vattenfall, eben im Morgenmagazin)
Montag, 7. August 2006
[Thema: augenblick-fingerfertig.de]
Ah ja, so will man den Webshop eigentlich haben. Ein guter Tipp, denn damit fallen viele Umbauarbeiten weg, die noch anstanden. Stattdessen Redesign der Oberfläche des OS Commerce hin zum Augenblick-Fingerfertig.de Design - erweitert um die schönen Funktionen, die OS Commerce mitbringt: Neueste Artikel, beliebteste Artikel, Benutzerverwaltung und so weiter. Der Urlaub ist gerettet!
... older stories