Mit Papier gewinnt man die Herzen der Studierenden

Zum Ende jedes Semesters führt die Fachschaft Informatik eine Vorlesungsevaluation durch, nennt dies aber “Vorlesungsumfrage” oder einfach nur kurz “VLU”1. Bis zum Wintersemester 2011/12 wurde diese über ein Online-System organisiert: Man bekam in der Vorlesung einen Zettel mit spezifischem Kennwort und konnte sich dann zu Hause am Rechner am System anmelden und die Veranstaltung bewerten.

Dies taten aber nur relativ wenige Studierende, und so beschloss man zum Sommersemester 2012, auf Umfragebögen aus Papier umzusteigen. Diese wurden nun in den Vorlesungen ausgegeben, per Hand ausgefüllt, direkt wieder eingesammelt und schließlich per Hand von fleißigen Fachschaftsbienchen ausgewertet – eine Heidenarbeit, aber der Rücklauf war subjektiv betrachtet deutlich höher.

Zum Wintersemester 2013/14, also eineinhalb Jahre später, führte man ein neues System ein, bei dem die Bögen maschinell ausgewertet werden können sollten. Mittlerweile klappt dies auch zuverlässig, und nur noch die Freitextfelder am Ende des Fragebogens müssen händisch abgetippt werden.

Immer wieder begegnet uns dabei die Anregung/Bitte/Aufforderung, doch ein Onlinesystem statt der Papierbögen zu verwenden, das sei viel praktischer und cooler und so, und: “Damit wäre sichergestellt, dass viele Leute teilnehmen.”2 Brahaha.

Doch halt. Hat eigentlich schon einmal jemand überprüft, ob unsere Ursprungsthese von 2012 sich bewahrheitet hat? Machen wir das doch einmal. Die Evaluation der Evaluation. Um dann endlich mal harte Zahlen auf den Tisch packen zu können.

Ich habe mir zum einen die VLU-Ergebnisse der letzten 8 Semester angesehen, und für jede Vorlesung die jeweiligen Teilnehmerzahlen notiert. Dieser Zeitraum umfasst 4 Semester mit Papierbögen und 4 Semester mit dem Onlinesystem.

Dann habe ich mir aus dem Verzeichnis der Informatik, das eine Zusammenfassung der Prüfungsergebnisse seit dem Wintersemester 2007/08 bietet3, zu diesen Vorlesungen die Zahl der Prüfungsteilnehmer notiert und bin davon ausgegangen, dass es sich bei diesen Personen um potenzielle VLU-Teilnehmer handelt. Dass diese Rechnung nicht ganz aufgeht, merkt man spätestens, wenn Teilnahmeraten von über 200 % herauskommen4

Werfen wir zunächst einen Blick auf die Zahl der Rückmeldungen. Vorlesungen mit nur 1 Rückmeldung sind rot markiert.

Gelb markiert die Papierbögen, blau markiert das Onlinesystem.

Gelb markiert die Papierbögen, blau markiert das Onlinesystem.

Auffällig ist bereits hier, dass es mit dem Onlinesystem sehr viele Veranstaltungen gab, für die lediglich 1 Rückmeldung erfolgte. Das Sommersemester 2011 tut sich hier besonders hervor. Das wäre schon mal ein Indiz dafür, dass die Bewertungslust beim Onlinesystem geringer war.

Doch blicken wir nun auf das Verhältnis von abgegebenen Bögen/Bewertungen zu Klausurteilnahmen.

Die Farbskala reicht hier von Rot (sehr wenige Rückmeldungen) bis Grün (alle Teilnehmer haben eine Bewertung abgegeben)

Die Farbskala reicht hier von Rot (sehr wenige Rückmeldungen) bis Grün (alle zur Klausur angemeldeten haben eine Bewertung abgegeben).

Bei diesem Bild können wir uns tiefgehende stochastische Analysen sparen: Während die Onlineumfrage (blau) im rot-braunen Bereich herumdümpelt, bewegt sich die Evaluation auf Papier (gelb) vorrangig im dunkel- bis sogar hellgrünen Bereich. Am “Diplomerknick” alleine kann dieser sprunghafte Anstieg sicherlich nicht liegen.

Sorgenkinder sind noch die Pflichtvorlesungen, hier mit einem x in der Spalte ganz links markiert. Diese produzieren zwar generell die meisten ausgefüllten Bögen, haben aber mutmaßlich auch die höchsten Dunkelziffern an Personen, die zwar zur Klausur wollen, die Vorlesung aber nicht besuchen.

Fazit: Offensichtlich generieren Papierfragebögen mehr Rückmeldungen als die Evaluierung über ein Online-System. Gut zu wissen.

Rohdaten als ods-Datei herunterladen
  1. sprich: “Fau-Ell-Uuh”. Oder nur: “Fluuuh” ↩
  2. Vorabveröffentlichung eines Kommentars aus der aktuellen VLU – Erscheinungsdatum: bald. ↩
  3. Siehe http://bree.iai.uni-bonn.de/informatik-intern/Ergebnisse/, nur aus dem Informatiknetz abrufbar. ↩
  4. siehe zweite Grafik; 5 Klausurteilnahmen vs. 12 VLU-Bögen im Sommersemester 2012. Das liegt wahrscheinlich daran, dass in der Statistik des Instituts Diplomstudierende nicht berücksichtigt werden, aber 7 von ihnen einen VLU-Bogen ausgefüllt hatten. ↩

SQL-Injection für Einsteiger

Es gibt viele Internetdienste, bei denen man sich mit Benutzernamen und Passwort anmelden muss. Das Formular sieht dann zum Beispiel so aus:

Eine handelsübliche Loginmaske.

Eine handelsübliche Loginmaske.

Total einfach: Man trägt seinen Benutzernamen (z. B. hszemi) und sei Passwort (z. B. geheim) ein, klickt auf “Anmelden” und wird auf die Startseite des “internen” Bereichs weitergeleitet.

Basics

Im Hintergrund läuft dabei in der Regel Folgendes ab:

Es gibt einen Datenbankserver mit einer Datenbank, in der sich eine Tabelle befindet, in der alle Benutzerkonten eingetragen sind: In der Spalte “benutzername” steht der jeweilige Benutzername und in der Spalte “passwort” jeweils das dazugehörige Passwort – allerdings nicht im Klartext1, sondern in der Regel wird eine Einwegfunktion verwendet (zum Beispiel MD5), die aus dem Passwort eine Prüfsumme berechnet, und lediglich die wird in der Datenbank gespeichert.

Das hat den Vorteil, dass jemand, der Zugriff auf die Datenbank hat, nicht die Passwörter sieht, sondern theoretisch so lange Wörter durch die Einwegfunktion jagen muss, bis zufällig einmal die richtige Prüfsumme herauskommt.

Die Benutzertabelle in der Datenbank sieht also etwa so aus:

ID benutzername passwort
1 Safura 4fdf7cf087cbf024d2e50a14256016f7
2 Erna 908fc4942e1f629d4c6629808da70165
3 Hans ccd5cc2741cd6347ac791e76e3062528
4 Jean b195d8b5aee9b903334bc8360099a90f

Zurück zum Login-Formular. Wird auf den “Anmelden”-Knopf geklickt, so werden an den Webserver die Inhalte der beiden Textfelder gesendet. Dort wird dann geprüft, ob es eine Zeile in der Benutzertabelle gibt, in der in der Spalte “benutzername” der Text aus dem Formularfeld “Benutzername” steht UND in deren Passwortfeld der Wert steht, der herauskommt, wenn man die Einwegfunktion auf den Inhalt des Formularfelds “Passwort” anwendet.

Solche Datenbankabfragen werden gemeinhin in einer eigenen Sprache formuliert, der “Structured Query Language” oder kurz “SQL”. Das ist eine Art sehr einfaches Englisch. Eine einfache SQL-Anfrage hat folgende Struktur:

SELECT (Liste von Tabellenspalten oder einfach * für alle Spalten)
FROM (Liste von Tabellen, aus denen die Spalten kommen)
WHERE (Bedingungen, um die Zeilen auszuwählen)

Wenn sich nun also Hans mit dem Passwort hanspasswort anmelden will, müsste folgende Anfrage ausgeführt werden:

SELECT *
FROM benutzer
WHERE benutzername = ‘Hans’ AND passwort = MD5(‘hanspasswort’)2

Wenn die Anfrage eine Zeile als Ergebnis zurückliefert, hat Hans das richtige Passwort eingegeben und darf in den “internen” Bereich. Falls es keine Zeile in der Tabelle gibt, die beide Bedingungen erfüllt, hat Hans ein falsches Passwort eingegeben und muss draußen bleiben.

Der Angriff

Die SQL-Abfrage muss nun allerdings für jeden Anmeldevorgang dynamisch zusammengebastelt werden. Nehmen wir an, der eingegebene Benutzername steckt immer in der Variable $BENUTZER und das eingegebene Passwort in der Variable $PASSWORT. Dann könnte man folgende SQL-Abfrage ausführen:

SELECT *
FROM benutzer
WHERE benutzername = ‘$BENUTZER‘ AND passwort = MD5(‘$PASSWORT‘)

Das blöde dabei: So eine SQL-Abfrage ist erstmal nur ein gewöhnlicher String (heißt eine Zeichenkette). Man könnte jetzt als Benutzernamen folgendes eingeben:

Safura’ OR ‘1’ = ‘1

Dann wird aus dem WHERE-Teil (der die Auswahl der Zeilen bestimmt) folgendes:

WHERE benutzername = ‘Safura’ OR ‘1’ = ‘1’ AND passwort = MD5(‘…’)

Da in SQL eine UND-Verknüpfung (AND) vor einer ODER-Verknüpfung (OR) ausgewertet wird und ‘1’ = ‘1’ logischerweise immer den Wert WAHR hat, werden plötzlich alle Zeilen zurückgeliefert, in denen entweder der Benutzername gleich Safura oder das eingegebene Passwort hinterlegt ist, oder beides.

Das heißt, mit diesem Trick kann man sich als jeder beliebige Nutzer anmelden, ohne das Passwort zu kennen. Alternativ kann man auch einen Quatsch-Benutzernamen angeben und als Passwort häufig genutzte Passwörter durchraten und wird bei einem Treffer als der Benutzer angemeldet, dessen Passwort man erraten hat – ohne zuvor den Benutzernamen zu kennen.

Warum funktioniert das?

Beim Zusammenbasteln der Anfrage oben wurden die Benutzereingaben direkt verwendet. Der eingegebene Benutzername wurde dann so gewählt, dass er zur Grundstuktur der SQL-Anfrage passt, aber ein anderes (vom Angreifer gewünschtes) Ergebnis zurückgeliefert wird. Durch die Anführungszeichen wird der eigentliche Benutzername beendet und das folgende OR wird als SQL-Schlüsselwort (statt als Inhalt des Benutzernamens) behandelt – mit fatalen Folgen.

Was tut man dagegen?

Eine der wichtigsten Regeln beim Programmieren: Vertraue gar niemals nicht irgendwelchen Benutzereingaben. Dass im obigen Beispiel der eingegebene Benutzername ohne vorherige Prüfung einfach so in die SQL-Abfrage eingebaut wird, ist grob fahrlässig – was leider nicht heißt, dass so etwas in der freien Wildbahn nicht vorkommt.

Für Datenbankabfragen die Variablen enthalten sollte man wo möglich Prepared Statements verwenden, die sich darum kümmern, dass eine Zahl wirklich eine Zahl und ein String wirklich ein String bleibt, und entsprechende problematische Zeichen zuverlässig herausfiltern.

Falls dafür ein Umbau der gesamten Webanwendung nötig und dieser zu aufwändig wäre, sollte man als Sofortmaßnahme auf jeden Fall die Benutzereingaben vorfiltern. PHP bietet hier zum Beispiel die Funktion mysqli_real_escape_string() an, die das übernimmt.

Die “abgehärtete” Datenbankabfrage sähe dann so aus:

SELECT *
FROM benutzer
WHERE benutzername = ‘mysqli_real_escape_string($BENUTZER)‘
AND passwort = MD5(‘mysqli_real_escape_string($PASSWORT)‘)

Fazit

Nun gut, diese Sicherheitslücke ist also bei uns drin.
Die Reparatur würde aber Geld und/oder Zeit kosten, deshalb machen wir da nix. Das weiß schließlich keiner dass die Lücke da ist und wie man sie ausnutzt weiß außer Ihnen auch niemand.

Ääh ja. SQL-Injections gehören zum kleinen 1×1 eines jeden Skriptkiddies. Gutes Gelingen 🙂

  1. Wobei es das auch gibt. Sollte man das machen? ↩
  2. MD5(‘hanspasswort’) berechnet in diesem Fall den Wert der Einwegfunktion für die Eingabe ‘hanspasswort’ ↩

Auflösungserscheinungen

Wohnheim Pariser Straße

Bald gehen im Wohnheim Pariser Straße die Lichter aus (Symbolbild)

Im Wohnheim Pariser Straße ist am 31. März 2015 Schluss. (Theoretisch voraussichtlich.) Das heißt, noch ein Semester, dann wohnt hier niemand mehr.

In den meisten Wohnheimen des Studentenwerks Bonn gibt es eine studentische Selbstverwaltung die sich “um das Haus kümmert”, eigene Finanzen verwaltet und teilweise sogar dem Studentenwerk Arbeit abnimmt. Für diese Ämter kann man sich von der Hausgemeinschaft wählen lassen und ist dann ein “Funktionsträger”.

Seit der Plan im Raum steht, das Wohnheim zu entmieten, werden vom Studentenwerk natürlich nur noch kurzfristige Mietverträge vergeben, was eben zur Folge hat, dass die Zahl der Langzeitmieter stetig schrumpft und die Hausgemeinschaft zerfällt.

Konkret kann man das an der letzten Hausvollversammlung festmachen. Auf der letzten Hausvollversammlung im Semester werden immer die Funktionsträger für das nächste Semester gewählt. Jene Hausvollversammlung bestand aber praktisch nur noch aus einem Teil der Funktionsträger, die größtenteils wiedergewählt werden wollten. Neue Gesichter gab es keine. Viele Funktionsträgerämter konnten deshalb nicht voll besetzt werden.

Dieser traurige Rest kann nun wenigstens noch die Restgeldbestände auf den Kopf hauen1.
Sic transit gloria wopsi.

Ich bin ja gespannt, wann das Studentenwerk sich mal zu Ende überlegt hat, wann und wie das mit der Entmietung funktionieren soll. Dazu gab es nämlich bislang noch keine Informationen an die Hausbewohner.

  1. in Form von Veranstaltungen, die allen Hausbewohnern zu Gute kommen ↩