Bearbeiten von „STiNE-Sicherheitslücken“

Natürlich ist [[STiNE]] nicht nur ein großes, langsames Softwaresystem, es enthält auch ein paar Sicherheitslücken. Da es unfein ist, sie einfach so zu veröffentlichen, bekommen die Datenlotsen generell ein bißchen Vorsprung, um die Lücken zu schließen.

= Ablauf, wenn Du eine neue Sicherheitslücke findest =

* Sicherheitslücke ''grob'' beschreiben
* Datenlotsen benachrichtigen
* Je nach Sachlage 21 Tage später die Sicherheitslücke (nach Absprache) veröffentlichen

= Sessionübernahme per HTTP-Referrer =

dumdidum.

Verlauf:
* 09.10.2006: Lücke entdeckt ([[Roland Illig]]).
* 10.10.2006: Datenlotsen benachrichtigt.
* 01.04.2014 (Ja, wirklich nach SIEBEN Jahren!): Lücke behoben (allerdings vor ein paar Wochen schon)

= Cross-Site-Scripting beim Anzeigen von STiNE-Nachrichten =

Beim Verfassen einer STiNE-Nachricht konnte man beliebigen HTML-Code in die Nachricht einbetten,
der 1:1 im Browser des Empfängers angezeigt wurde.

Verlauf:
* 10.10.2006: Lücke entdeckt ([[Roland Illig]]).
* 10.10.2006: Datenlotsen benachrichtigt.
* 17.10.2006: Die Sicherheitslücke ist behoben.
* 17.10.2006: Details angehängt

= Unbeabsichtigte Einsicht in STiNE-Nachrichten beliebiger Benutzer =

Im [[STiNE-Modul MESSDETAIL]] konnte man einfach die Nachrichten-ID auf einen beliebigen Wert setzen, und wenn die Nachricht vorhanden war, wurde sie angezeigt, egal, ob sie für den gerade angemeldeten Benutzer bestimmt war.

Verlauf:
* 10.10.2006: Lücke entdeckt.
* irgendwann dazwischen: STiNE-Projektleitung benachrichtigt (mündlich, vielleicht auch schriftlich).
* 17.10.2006: Die Sicherheitslücke ist behoben.
* 18.10.2006: Details veröffentlicht.

= Und so weiter ... =

Das ist bei weitem nicht alles. Ohne große Anstrengung kann man mit wenig Fachwissen jede Menge weiterer Sicherheitslücken finden. Der umfassende Datenschutz, der in der [http://www.info.stine.uni-hamburg.de/stud_faq.html STiNE-FAQ] angepriesen wird, ist bei weitem nicht eingehalten. [16.10.2006]

Es macht allerdings den Eindruck, als ob die Datenlotsen jetzt erkannt haben, dass Softwaresicherheit wichtig ist (siehe auch [[STiNE-Tagebuch]]).

= ... und so weiter ... =

Übrigens machen nicht nur die Datenlotsen so schlechte Software. Die Firma [http://www.magicsoftware.com/ Magic Software], auf deren Middleware STiNE aufbaut, weiß auch noch nicht, was SQL-Injections sind, wie deren Entwicklerdoku zu eDeveloper beweist. (Update vom 22.05.2007: Das scheint mittlerweile behoben zu sein. --[[Roland Illig]])

= Unberechtigter Zugriff auf personenbezogene Dokumente =

Durch gezieltes Raten ist es einem Angreifer möglich, auf die persönlichen Dokumente (zur Zeit Semesterbescheinigungen und Studienbuch) anderer STiNE-Benutzer zuzugreifen. Das funktioniert im Prinzip wie damals mit den STiNE-Nachrichten, nur dass die Dokumenten-IDs jetzt nicht mehr fortlaufend numeriert sind.

Verlauf:
* 26.09.2007: Lücke entdeckt.
* 26.09.2007: Datenlotsen benachrichtigt.
* 27.09.2007, 14:50: Lücke behoben, die Mail über das Beheben habe ich jedoch erst am 01.10. bekommen. :)
* 01.10.2007: Details veröffentlicht.

== Details ==
Das Herunterladen von Dateien, die von STiNE verwaltet werden, geschieht nicht innerhalb von Magic, sondern mit einem externen Programm (filetransfer.dll). Das bekommt die folgenden Parameter:
* PATH_INFO: "download" oder "upload" (wie letzteres geht, weiß ich allerdings noch nicht. ;))
* session: Die Session-ID
* fnsrc: Der Name der Datei auf dem Server
* fndest: Der Name der Datei, wie ihn der Benutzer sehen soll
* subdir: Das Verzeichnis, aus dem die Datei kommt. Mir wurde gesagt, dass es sich hierbei um "logische" Verzeichnisse handelt, so dass Angriffe der Form "subdir=../../../.." zwecklos seien.

Das Problem war nun, dass die Session-ID anscheinend garnicht überprüft wurde, denn man konnte die Dokumente auch herunterladen, wenn die Session-ID 0 war. Die Folge davon war, dass man die Datei auch noch herunterladen konnte, nachdem man ausgeloggt war, wenn man nur die URL kannte. Und selbst wenn man die URL nicht kannte, konnte man doch durch "gezieltes Raten" versuchen, an Dokumente heranzukommen, wenn man den ungefähren Zeitpunkt kannte, zu dem das Dokument in STiNE erzeugt wurde. Denn danach richtet sich der Dateiname fnsrc, der die Form "f" + STiNE-ID + ".cache" hat.

== Kommentare ==
Kommentar: Als ich mal damit gespielt habe, ging das mit der Terminexportfunktion ähnlich. --[[MartinBurmester]]
: Ja, stimmt, hatten wir das gar nicht erwähnt? ;) Ich wollte es eigentlich ausprobieren, aber da ich keine Termine habe, kann ich auch nichts exportieren. Ich bin trotzdem neugierig, wie lange die Dateien aufgehoben werden. --[[Roland Illig]]

Diese Sicherheitslücke sollte mittlerweile komplett behoben sein. Wer sich dennoch daran versuchen will, kann ja mal versuchen, meine Semesterbescheinigungen zu bekommen. Sie sind unter der ID fnsrc=f329444333092776.cache gespeichert. --[[Roland Illig]]

[[Kategorie:STiNE]]