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:

1. Session Hijacking, um die Session eines Benutzers mitbenutzen zu können, ohne sein Passwort eingegeben zu haben.
2. Parameter-Veränderung um an Daten anderer Benutzer zu gelangen.
3. Code Injection in den Server über einen File-Upload.

Daraufhin stellt sich die Frage, ob auch OS Commerce wie die dort beschriebene Web-Applikation angreifbar ist.

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
nach dem Speichern den Text

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.