Leseprobe
Inhaltsverzeichnis
ABKÜRZUNGSVERZEICHNIS
ABBILDUNGSVERZEICHNIS
QUELLCODE-BEISPIELE
1. EINLEITUNG
2. DATENSCHUTZ UND DATENSICHERHEIT
2.1 Datenschutzaspekte von Klausuranmeldungen
2.1.1 Definition des Begriffs Datenschutz
2.1.2 Entwicklung des Datenschutzes
2.1.3 Geltungsbereiche der Datenschutzgesetze
2.1.4 Richtlinien für den Datenschutz
2.1.5 Veröffentlichung von Klausurergebnissen
2.2 Bedrohungsszenarien für Internetanwendungen
2.2.1 Definition des Begriffs Datensicherheit
2.2.2 Schäden durch Bedrohungen
2.2.3 Bedrohungsszenario SQL-Injection
2.2.4 Maßnahmen zum Schutz des Datenbanksystems
2.2.5 Maßnahmen zum Schutz von PHP/ MYSQL -Anwendungen
2.2.6 Bedrohungsszenario Cross-Site-Scripting
2.2.7 Angriffsflächen bei der Übergabe von Variablen
3. VORSTELLUNG DES „KASIB“
3.1 Mängel der bisherigen Lösung
3.2 Öffentlicher Bereich des Systems
3.2.1 Erstanmeldung
3.2.2 Anmeldung über Benutzername und Passwort
3.2.3 Abmeldung
3.2.4 Auflistung der Klausuranmeldungen
3.3 Verwaltungsbereich
3.3.1 Neue Klausur hinzufügen
3.3.2 Angaben eines Klausurtermins ändern
3.3.3 Noten zu einer Klausur eintragen
3.3.4 Link zu veröffentlichten Klausurergebnissen mailen
3.3.5 Daten exportieren
4. SICHERHEITSASPEKTE DES SYSTEMS
4.1 Überprüfung auf Einhaltung der Datenschutzbestimmungen
4.1.1 Erfassung der Anmeldedaten
4.1.2 Veröffentlichung von Prüfungsergebnissen über die Anwendung
4.2 Datensicherheit des KASIB
4.2.1 Architektur
4.2.2 Programmablauf und Fehlerbehandlung
5. VORSTELLUNG ANDERER KLAUSURANMELDESYSTEME
5.1 Virtuelles Prüfungsamt der Fachhochschule Bielefeld
5.1.1 Architektur
5.1.2 Öffentlicher Bereich
5.1.3 Verwaltungsbereich
5.1.4 Administrationsfunktionen
5.1.5 Fazit
5.2 FlexNow
5.2.1 Architektur
5.2.2 Öffentlicher Bereich
5.2.3 Verwaltungsbereich
5.2.4 Fazit
6. FAZIT UND AUSBLICK
7. DANKSAGUNGEN
8. LITERATURVERZEICHNIS
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abb. 1: Zunahme der Bedrohungen durch Viren, Würmer, Trojaner
Abb. 2: Beispielhaftes Eingabeformular
Abb. 3: Definition des Datenfeldes „ Matrikelnummer“ in der Datenbank
Abb. 4: Konfigurationseinstellungen des Apache Webservers
Abb. 5: Ergebnis der Ausführung
Abb. 6: Ergebnis der Ausführung
Abb. 7: Beispielhafte Übergabe von Daten über die URL
Abb. 8: Formular zur Klausuranmeldung im Sommersemester 2004
Abb. 9: Dateien des öffentlichen Bereichs
Abb. 10: Weitere Interaktionsmöglichkeiten
Abb. 11: Anmeldeformular zur Erstanmeldung
Abb. 12: Anmeldebestätigung
Abb. 13: Anmeldung über Benutzername und Passwort
Abb. 14: Auswahl der Klausuren bei Anmeldung über Benutzername und Passwort
Abb. 15: Übersicht der Klausuren, zu denen ein Nutzer aktuell angemeldet ist
Abb. 16: Dateien des Verwaltungsbereichs
Abb. 17: Übersicht der Verwaltungsfunktionen
Abb. 18: Eingabeformular für eine neue Veranstaltung
Abb. 19: Weitere Interaktionsmöglichkeiten
Abb. 20: Auswahl des zu editierenden Klausurtermins
Abb. 21: Übersicht geänderter Daten und informierter Personen
Abb. 22: Formular zur Noteneingabe
Abb. 23: Bestätigung Zustellung des Links zu den Prüfungsergebnissen
Abb. 24: Übersicht der exportierten Daten
Abb. 25: Anmeldeformular zur Erstanmeldung
Abb. 26: Fehlermeldung bei unberechtigtem oder wiederholtem Zugriff
Abb. 27 Anmeldeseite des ViPa
Abb. 28: Leistungsübersicht
Abb. 29: FlexNow-Architektur
Abb. 30: Abbildung der Universitätsstruktur in FlexNow
Abb. 31: Benutzeroberfläche für Studierende
Abb. 32: Personalisiertes Anmeldeformular
Abb. 33: Studentendaten
Abb. 34: Bedeutung der verwendeten Symbole
Abb. 35: Auswahl der Sichten auf die Daten
Abb. 36: Automatisch generiertes Zeugnis
Abb. 37: Formular zum Noten eintragen
Quellcode-Beispiele
Quellcode-Beispiel 1: Quellcode eines einfachen Eingabeformulars
Quellcode-Beispiel 2: Quellcode des weiterverarbeitenden Skriptes
Quellcode-Beispiel 3: Definition des Eingabefeldes für die Matrikelnummer
Quellcode-Beispiel 4: Ausführung schadhaften Codes
Quellcode-Beispiel 5: Ausführung schadhaften Codes wird verhindert
Quellcode-Beispiel 6: Mailfunktion in der Datei „Mailbestaetigung.php“
Quellcode-Beispiel 7: Fehlerbehandlung mittels Try-Catch
1. Einleitung
In Zeiten knapper Haushaltsmittel sehen sich auch die Universitäten gezwungen, die vorhandenen materiellen und personellen Ressourcen optimal zu nutzen. In der Verwaltung macht sich dieser Sparzwang besonders bemerkbar. Immer mehr Aufgaben müssen durch immer weniger Personal bewältigt werden, was oft zu langen Bearbeitungszeiten führt. Durch den Einsatz moderner Informations- und Kommunikationstechnologien lassen sich einige dieser Arbeiten automatisieren. Eine Verwaltungsaufgabe, die jedes Institut an einer Universität zu leisten hat, ist die Abnahme von Prüfungsleistungen. Dieser mehrstufige Prozess wird an vielen Einrichtungen nach wie vor persönlich vom Institutssekretariat oder den Prüfern selbst koordiniert.
Das Institut für Betriebswirtschaftslehre nutzt seit einigen Jahren eine internetgestützte Klausuranmeldung, die bisher aber nur eine Behelfslösung darstellte. Ziel dieser Arbeit ist es, das bisherige Verfahren der onlinebasierten Klausuranmeldung des Instituts für Betriebswirtschaftslehre zu optimieren. Dabei müssen vor allem datenschutzrechtliche Aspekte berücksichtigt und mögliche Angriffsszenarien betrachtet werden, welche die Datensicherheit beeinträchtigen können. Diese Umfeldfaktoren werden in Kapitel 2 der Arbeit vorgestellt. Dem Leser soll aufgezeigt werden, welche äußeren Einflüsse auf die Entwicklung des KASIB1 einwirkten.
Um nicht nur theoretisch die durch KASIB unterstützten Arbeitsabläufe abzuhandeln, wird der Funktionsumfang in Kapitel 3 ausführlich anhand von Screenshots beschrieben. Der darauf folgende Abschnitt betrachtet die entwickelte Anwendung im Kontext von Datenschutz und Datensicherheit. Es wird beleuchtet, wie Datenschutzanforderungen berücksichtigt und eine hohe Datensicherheit gewährleistet werden.
Ein Vorstellung der Anmeldesystemen anderer Universitäten im 5. Kapitel soll einen umfassenderen Einblick in den Themenbereich bieten. Dabei wird erklärt, welche unterschiedlichen Ansätze möglich sind und wie eine solche Anwendung in den Gesamtverbund der IT-Systeme einer Universität eingebunden werden kann. Die Arbeit schließt mit einem Fazit, bei dem die gewonnenen Erkenntnisse zusammengefasst und ferner Erweiterungsmöglichkeiten der entwickelten Software aufgezeigt werden.
2. Datenschutz und Datensicherheit
Datenschutz und Datensicherheit sind zwei eng korrelierende Einflussfaktoren auf die Entwicklung von Internetanwendungen. In diesem Abschnitt sollen dem Leser zunächst die Grundsätze des Datenschutzes näher gebracht werden.
Datenschutz ist ohne eine ausreichende Datensicherheit jedoch nicht zu gewährleisten, Deshalb werden in Abschnitt 2.2 weiterhin mögliche Angriffsszenarien analysiert und auf bei der Programmierung zu berücksichtigende Sicherheitsaspekte hingewiesen.
2.1 Datenschutzaspekte von Klausuranmeldungen
Da bei der Prüfungsanmeldung personenbezogene Daten verarbeitet werden, müssen bestimmte Datenschutzvorschriften beachtet werden. An eine internetgestützte Klausuranmeldung werden besondere Anforderungen gestellt. Welche Bestimmungen zu berücksichtigen sind, wird in diesem Kapitel erläutert.
2.1.1 Definition des Begriffs Datenschutz
Einleitend ist zunächst zu erläutern, was juristisch unter dem Begriff Datenschutz zu verstehen ist:
Datenschutz ist Schutz der Privatsphäre und nicht Schutz der Daten2.
Ziel des Datenschutzes nach §1 Bundesdatenschutzgesetz (BDSG) ist der Schutz des Einzelnen vor der Beeinträchtigung seines Persönlichkeitsrechts beim Umgang mit seinen personenbezogenen Daten. Personenbezogene Daten sind laut §3 BDSG „Einzelangaben über persönliche und sachliche Verhältnisse einer bestimmten oder bestimmbaren natürlichen Person (Betroffener)“.
2.1.2 Entwicklung des Datenschutzes
Die grundsätzlichen Aspekte des Datenschutzes fußen auf dem Verfassungsrecht. Es ist Aufgabe des Staates, durch die Gesetzgebung das in Artikel 1 und 2 des Grundgesetzes manifestierte Persönlichkeitsrecht jedes Bürgers zu bewahren.
Ausschlaggebend für den heutigen Datenschutz ist das so genannte Volkszählungsurteil vom 15.11.1983, welches den Schutz des Einzelnen gegen unbegrenzte Erhebung und Speicherung, Verwendung und Weitergabe seiner persönlichen Daten gewährleistet [Helmer 2003, S. 9]. Das Grundrecht gewährleistet dem Einzelnen, selbst über die Preisgabe seiner persönlichen Daten zu bestimmen.
Bachelor-Abschlussarbeit im Studiengang IMIT Marcel Minke Das BDSG basiert in seiner heutigen Form in weiten Teilen auf der EG-Datenschutzrichtlinie von 1995, welche das Ziel hatte, die verschiedenen Datenschutzbestimmungen der einzelnen EU-Mitgliedsstaaten bis Oktober 1998 zu vereinheitlichen. In Deutschland wurde diese Richtlinie endgültig erst 2001 in nationales Recht umgesetzt und das BDSG novelliert.
2.1.3 Geltungsbereiche der Datenschutzgesetze
Für die Universität Hildesheim gilt neben den allgemeinen Datenschutzregeln und dem BDSG insbesondere das niedersächsische Landesdatenschutzgesetz (NdsDSG). Allgemein lässt sich festhalten, dass das jeweilige LDSG das Datenschutz-Grundrecht für öffentliche Stellen des Landes und der Kommunen [§2 NdsDSG] regelt, während das BDSG nur für öffentliche Stellen des Bundes, nicht aber der Länder gilt [§1 BDSG]. Daneben bestehen weitere bereichsspezifische Datenschutzregelungen in anderen Gesetzen, welche die allgemeinen Regelungen in den Landesdatenschutzgesetzen verdrängen. Für Hochschulen sind dabei das Beamtengesetz und vor allem das Hochschulgesetz zu nennen.
In den meisten Hochschulen regeln interne Verordnungen die Erhebung und Verarbeitung personenbezogener Daten bei der Immatrikulation und bei der weiteren hochschulinternen Verwaltung. Darin ist u.a. festgehalten, welche Daten erhoben werden dürfen und wann diese wieder gelöscht werden müssen. Bei Verarbeitung der Matrikelnummer kann es je nach gegebenem Hochschulgesetz notwendig sein, dies in die Satzung der Hochschule aufzunehmen. Dieser Fall trifft auf die Berliner Universitäten zu, denen es nach §6 Absatz 7 des Berliner Hochschulgesetzes lediglich erlaubt ist Name, Anschrift und Geburtsdatum zu verarbeiten.
2.1.4 Richtlinien für den Datenschutz
Bei der Datenerhebung ist grundsätzlich die Prämisse der Datenvermeidung und Datensparsamkeit [§3a BDSG] zu beachten. Es sollten nur so viele personenbezogene Daten erhoben werden, wie es zur Erfüllung einer Aufgabe unbedingt nötig ist. Dabei sollte von den Möglichkeiten der Anonymisierung und Pseudonymisierung Gebrauch gemacht werden. Anonymisierung bezeichnet eine Veränderung der Daten dahingehend, dass der Personenbezug entfällt oder sich nur durch einen unverhältnismäßig hohen Aufwand wieder herstellen lässt.Pseudonymisierung beschreibt das Ersetzen des Namens oder anderer Identifikationsmerkmale durch ein bestimmtes Kennzeichen mit dem Ziel, die Bestimmung des Betroffenen auszuschließen oder wesentlich zu erschweren [Helmer 2003, S. 35].
Ein geläufiges Beispiel für eine Pseudonymisierung ist die Zuweisung einer Matrikelnummer zu einem Studierenden. Dazu ist anzumerken, dass viele vergebene Matrikelnummern meistens gewisse Rückschlüsse zulassen. An der Universität Hildesheim lässt sich über die ersten drei Ziffern jeder Matrikelnummer in etwa das Immatrikulationsjahr bestimmen, da sie blockweise vergeben werden. Für jedes Jahr wird immer ein neuer Block festgelegt, aus denen ein Algorithmus die einzelnen Matrikelnummern erzeugt3. Dadurch wird es Dritten erleichtert, den Bezug zwischen einer Matrikelnummer und einer bestimmten Person herzustellen, da durch die ersten drei Ziffern der Kreis der in Frage kommenden Personen schon stark eingeschränkt wird. Die Vergabe der Matrikelnummer an der Universität Hildesheim ist daher datenschutzrechtlich als bedenklich einzustufen, da laut gesetzlicher Vorgabe Dritte keine Möglichkeit erhalten sollen, von der Matrikelnummer auf die jeweilige Person zu schließen [Dix 1995].
Anstatt einer fortlaufenden Nummer, die Rückschlüsse auf das Immatrikulationsjahr zulässt, wäre ein zufällig erzeugter Schlüssel bestimmter Länge empfehlenswert. Ein solcher Schlüssel ließe keinerlei Rückschlüsse auf eine spezifische Person oder einen gewissen Personenkreis mehr zu und würde den Anforderungen des Datenschutzes in allen Fällen genügen.
Aus dem Grundrecht auf informelle Selbstbestimmung hervorgegangen ist das in §4 BDSG festgehaltene generelle Verbot der Verarbeitung personenbezogener Daten mit Erlaubnisvorbehalt. Das Recht auf informelle Selbstbestimmung darf nur im überwiegenden Allgemeininteresse eingeschränkt werden [Helmer 2003, S. 10], welches durch spezielle Rechtsvorschriften und in §28 BDSG genauer spezifiziert ist. Der Erlaubnisvorbehalt besagt, dass eine Einwilligung des Betroffenen vorliegen muss, bevor personenbezogene Daten erhoben werden dürfen. Dabei muss der Betroffene ausführlich über den Zweck der Erhebung, Verarbeitung und Nutzung informiert und auf die Folgen der Verweigerung hingewiesen werden. Abschließend muss er durch seine Unterschrift erklären, dass er die dargelegten Punkte verstanden hat. Da eine eigenhändige Unterschrift über eine internetbasierte Anwendung nicht zu leisten ist, wurde in §4a des BDSG eine Abweichung von der eigenhändig geleisteten Unterschrift „bei Vorliegen besonderer Umstände“ für zulässig erklärt [Helmer 2003, S. 42].
2.1.5 Veröffentlichung von Klausurergebnissen
An Hochschulen werden zurzeit verschiedenste Verfahren zur Bekanntgabe von Prüfungsergebnissen eingesetzt. Die Zeiten der Präsenz-Universität, in denen sich zum Semesterende noch einmal die Flure füllten und den Studierenden die Prüfungsergebnisse persönlich mitgeteilt wurden, sind vorbei. Bei den meisten Universitäten überwiegt die klassische Form der Bekanntgabe am schwarzen Brett. Dabei werden die Klausurergebnisse mit der Matrikelnummer, aber ohne den Namen der Prüfungsteilnehmer ausgehängt. Der Landesbeauftragte für den Datenschutz Rheinland-Pfalz, Rudolph, hält diese Art der Veröffentlichung für akzeptabel, da die Matrikelnummer zwar personenbeziehbar ist, das notwendige Zusatzwissen jedoch nur im Ausnahmefall und kaum aufgrund gezielter Bemühungen zu erlangen ist [Rudolph 2001].
Dieses Modell der Veröffentlichung ist jedoch nicht ohne weiteres auf das Internet übertragbar:
„Übermittelt eine Hochschule im Internet Informationen an Studenten, die zwar nicht mit dem Namen, aber mit Matrikelnummer gekennzeichnet sind, ist dies nur im Rahmen der Einwilligung zulässig.“[Hamm 1996]
Die universitäre Nutzung des Internets wirft vielfältige datenschutzrechtliche Fragen und Probleme auf, die oft gar nicht oder nur unbefriedigend gelöst werden können. Es zeigt sich, dass das Recht regelmäßig hinter der technischen Entwicklung hinterher hinkt. Viele wichtige Punkte sind oft noch nicht gesetzlich geregelt. Es existieren lediglich Empfehlungen verschiedener Datenschutzbeauftragter.
So sollen im Internet nur Listen mit Note - Matrikelnummer Zuordnungen veröffentlicht werden. Diese Listen sollten über Meta-Tags oder durch eine robots.txt-Datei4 von der Indexierung durch Suchmaschinen ausgeschlossen werden. Eine weitere Sicherheitsvorkehrung wäre, die Einsicht nur nach korrekter Eingabe eines Passworts zuzulassen oder den Zugriff auf die IP-Adressen der Universität zu beschränken [Blank o.J.]. Bei letztgenanntem Verfahren wird zunächst überprüft, von welchem Rechner auf die Auflistung der Prüfungsergebnisse zugegriffen wird. Wenn es sich dabei nicht um einen Rechner der Universität handelt, zu erkennen an der weltweit einmaligen IP-Adresse, so wird der Zugriff verhindert. Aus datenschutzrechtlicher Sicht ist diese Veröffentlichungsweise der Bekanntgabe der Prüfungsergebnisse über das schwarze Brett gleichzusetzen [Rudolph 2001]. Dieses Verfahren macht aber einen großen Vorteil der Veröffentlichung im Internet wett, den uneingeschränkten Zugriff von jedem Ort der Welt.
Einige Dozenten nutzen zur Bekanntgabe von Klausurergebnissen oder anderen wichtigen Mitteilungen an eine Gruppe von Personen die Rundmail-Funktion ihres E-Mail Programms. Dabei wird oft der Fehler begangen, dass einfach alle Adressaten in das CC5 -Feld eingetragen werden. So kann jeder Empfänger sehen, wer diese Mitteilung noch empfangen hat. Außerdem werden so die E-Mail Adressen aller Personen im gesamten Empfängerkreis bekannt gemacht. Dies zu vermeiden wird von den Datenschutzbeauftragten ausdrücklich empfohlen und kann erreicht werden, indem man alle Empfänger im BCC-Feld6 des Mailprogramms aufführt. Das KASIB umgeht den beschriebenen Problemfall, indem es an jeden Klausurteilnehmer separat eine E-Mail sendet (siehe Abschnitt 3.3.4, Seite 39).
Das unbefugte Lesen, Kopieren, Verändern und Löschen der Klausurergebnisse muss bei der Veröffentlichung im Internet verhindert werden. Die vom rheinland-pfälzischen Datenschutzbeauftragten empfohlenen Maßnahmen der verschlüsselten Übertragung und die Nutzung selbstextrahierender Archive scheinen nur sehr schwer realisierbar. Die erste Empfehlung beinhaltet einen Schlüsselaustausch und setzt auf beiden Seiten die Nutzung bestimmter Software voraus. Als Passwort für den Zugriff auf die Daten in selbstextrahierenden Archiven wird eine Kombination aus Immatrikulationsnummer und einer Zusatzinformation wie dem Geburtsdatum als ausreichend angesehen [Rudolph 2001]. Diese Vorgehensweise würde einen erheblichen Aufwand bedeuten, da für jeden Prüfungsteilnehmer ein eigenes Passwort erzeugt werden müsste und die veröffentlichende Stelle über Daten wie Matrikelnummer und Geburtsdatum verfügen muss. Weiterhin muss eine Liste erstellt werden, in der alle Zugangspasswörter gespeichert sind und die mit der Benutzereingabe abgeglichen werden muss. Beide Empfehlungen sind in ihrer dargelegten Form wegen des Aufwands kaum zu realisieren. Es zeigt sich, dass jede Lösung stets eine Abwägung zwischen einem größtmöglicher Datenschutz und einem komfortablen Zugriff erfordert.
Häufig werden Verstöße gegen den Datenschutz nicht absichtlich begangen. Wenn man die Tätigkeitsberichte der Datenschutzbeauftragten liest, stellt man fest, wie viele solcher Verstöße auf mangelnde Sorgfaltspflicht, fehlendes Wissen oder schlicht auf Bequemlichkeit des Verursachers zurück zu führen sind. Gerade im Hochschulbereich ist eine weitere Sensibilisierung der Mitarbeiter notwendig. Vielen fehlt es an grundlegenden Kenntnissen und Problembewusstsein.
2.2 Bedrohungsszenarien für Internetanwendungen
Der Begriff Datensicherheit wird heutzutage als Schlagwort in Werbeanzeigen u.a. für AntiViren-Software oder Firewall-Applikationen genutzt. Um genau festzulegen, in welchem Rahmen der Begriff in dieser Ausarbeitung genutzt wird, erfolgt zunächst eine genaue Definition zur Schaffung einer einheitlichen Verständnisgrundlage. Die Leser für das Thema Datensicherheit zu sensibilisieren ist Ziel des Abschnitts 2.2.2, in welchem die Folgen unzureichender Datensicherheit angesprochen werden. Abschließend erfolgt die Analyse einiger typischer Angriffszenarien auf Internetanwendungen.
2.2.1 Definition des Begriffs Datensicherheit
Datensicherheit bezeichnet die Bewahrung von Daten vor Beeinträchtigungen. Dazu zählen vor allem die Sicherstellung der Verfügbarkeit, der Integrität, der Verbindlichkeit und der Vertraulichkeit [Wikipedia 2005a]. Verfügbar sind Informationen und Kommunikationsverbindungen, wenn sie durch einen Anwender genutzt werden können. Integrität bezeichnet die unverfälschte Übermittlung von Daten zwischen zwei Kommunikationspunkten. Verbindlich sind kommunizierte Inhalte, wenn sie den jeweiligen Kommunikationspartnern einwandfrei zuzuordnen sind. Als vertraulich werden Informationen bezeichnet, die nur ausgewählten Teilnehmern bekannt sind [Winkel 2000].
Datensicherheit kann durch die räumliche und physische Sicherung der Daten, Einsatz von fehlertoleranten Systemen und Zugriffskontrollen erreicht werden. Unter datenschutzrechtlichen Aspekten ist vor allem letztgenannter Punkt zu beachten (siehe Abschnitt 4.1.2, Seite 45ff).
2.2.2 Schäden durch Bedrohungen
Welchen Stellenwert die Datensicherheit heutzutage einnimmt, zeigt sich, wenn man die ständig zunehmende Bedrohung durch Viren, Würmer und Trojaner betrachtet. Die Grafik zeigt die Anzahl der im jeweiligen Jahr durch Viren, Würmer und Trojaner vom CERT7 registrierten Angriffe:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 1: Zunahme der Bedrohungen durch Viren, Würmer, Trojaner, Nach [CERT 2004]
Die dadurch entstehenden Schäden sind immens. So richteten die VirenBlaster,WelchiaundSobigim August 2003 in nur 12 Tagen weltweit einen Schaden von 1,63 Milliarden Euro an [futureZone 2004]. In der Bundesrepublik erreichen die Schäden durch Computer-Viren jährlich eine dreistellige Millionenhöhe, mit steigender Tendenz [BSI 2004]. Die 2003 nur bei amerikanischen Banken und Kreditkartenunternehmen durch Phishing8 verursachten Verluste beliefen sich auf nahezu 1,2 Milliarden US-Dollar [Symantec 2004b]. Wenn man sich vor Augen hält, dass Phishing im Jahr 2003 gerade seine Anfänge nahm, offenbart sich ein ungeheueres Schadenspotential für die Wirtschaft.
Größere Unternehmen versuchen diesem Umstand Sorge zu tragen, indem sie umfangreiche Sicherheitsvorkehrungen treffen. Die dortigen IT-Verantwortlichen sehen sich jedoch vor enorme Herausforderungen gestellt. Wöchentlich werden im Durchschnitt 48 neue Schwachstellen aufgedeckt [Symantec 2004b]. Diese müssen protokolliert und entsprechende Patches verteilt werden. Selbst wenn sie diese Aufgabe bewältigen, bleibt immer noch das Problem, dass entsprechende Patches im Durchschnitt erst nach rund sechs Tagen zur Verfügung stehen. In dieser Zeit bietet sich nur die Möglichkeit, die betroffenen Programme einzuschränken oder ganz abzuschalten. Dieses Vorgehen erscheint notwendig, wenn man berücksichtigt, dass nur im ersten Halbjahr 2004 insgesamt 1237 neue Schwachstellen in Software aufgedeckt wurden, von denen 96 Prozent als mittleres oder hohes Risiko eingestuft wurden und 70 Prozent als leicht ausnutzbar klassifiziert wurden [Symantec 2004b].
Vor welche Probleme die Sicherheitsverantwortlichen gestellt sind, zeigt folgende Untersuchung von Symantec: Bei der Analyse der Quell-IP-Adressen verschiedener Würmer wurde ermittelt, dass von über 40% der Fortune 100-Unternehmen9 Wurmangriffe ausgingen. Das bedeutet jedoch nicht, dass diese Unternehmen direkt an den Angriffen beteiligt sind. Vielmehr sind die Angriff initiierenden Computersysteme dieser Unternehmen zuvor selbst Opfer externer Angriffe gewesen und wurden von den Angreifern nur zur weiteren Verbreitung des Schädlings missbraucht [vgl. Symantec 2004b].
2.2.3 Bedrohungsszenario SQL-Injection
Schon vor der eigentlichen Programmierung des KASIB wurden bereits im Vorfeld mögliche Sicherheitsrisiken analysiert, mit dem Ziel, diese Risiken im Laufe der Entwicklung zu minimieren. Bei Datenbankanwendungen stellt vor allem der Zugriffsprozess auf die Datensätze eine entscheidende Rolle. Viele Angriffsmethoden setzen an diesem Punkt an, da hier tief in das gesamte System eingegriffen werden kann. Ein weit verbreitetes Angriffsszenario ist die Erlangung von Zugriff auf die Datenbank über so genannte SQL- Injections (nach [1&1 Internet AG 2004], [Friedl 2005], [Kiesel 2003], [Wikipedia 2005b]). Sollen Benutzereingaben in einer Datenbank gespeichert werden, dann werden diese meist aus Formularfeldern ausgelesen und die ermittelten Werte werden an das Programm übergeben. Dieses baut intern eine Verbindung zur Datenbank auf und fügt die zwischengespeicherten Daten in die Datenbank ein.
Das folgende kurze Beispielprogramm soll diese einzelnen Vorgänge verdeutlichen:
Abb. 2: Beispielhaftes Eingabeformular
Abbildung in dieser Leseprobe nicht enthalten
Quellcode-Beispiel 1: Quellcode eines einfachen Eingabeformulars
Im Form-Tag (Zeile 10) wird zunächst festgelegt, an welche Datei die in den Eingabefeldern benutzername und passwort eingetragenen Daten weitergeleitet werden sollen. Die angegebene DateiSQL_Injection_Abfrage.php übernimmt die Werte daraufhin und verarbeitet sie:
Abbildung in dieser Leseprobe nicht enthalten
Quellcode-Beispiel 2: Quellcode des weiterverarbeitenden Skriptes
Dazu wird zunächst angegeben, auf welcher Datenbank die Operationen ausgeführt werden (Zeile 3). Danach werden alle Daten einer Person aus der Tabelle Kundendaten ermittelt, die unter dem zuvor im Eingabeformular eingegebenen Benutzernamen $_POST[benutzername] mit zugehörigem Passwort $_POST[passwort] eingetragen sind (Zeile 6). Abschließend wird die Anfrage auf die Datenbank ausgeführt (Zeile 9). Für den beispielhaften BenutzernamenMeiermit dem Passwortgeheimsähe die generierte Datenbankanfrage wie folgt aus:
SELECT * FROM kundendaten WHERE benutzername='Meier' AND passwort='geheim'
In der DateiSQL_Injection_Abfrage.phpwerden die eingegebenen Daten in einfachen Anführungszeichen in die Anfrage übernommen. Die Eingabedaten werden so durch das Programm als Strings interpretiert. Wenn nun in den benutzerveränderbaren Eingabedaten ebenfalls einfache Anführungszeichen enthalten sind und diese nicht vom Programm maskiert werden, kann dies wesentliche Auswirkungen auf die Datenbankanfrage haben. Angenommen ein Angreifer möchte die Daten des BenutzersMeierermitteln, ist aber nicht in Besitz des Passwortes. Die Eingabe vonMeierals Benutzername und„’OR 1=1“als Passwort kann schon zum Erfolg führen. Ein Blick auf die Umsetzung der Anfrage offenbart Erstaunliches:
SELECT * FROM kundendaten WHERE benutzername='Meier' AND passwort='' OR 1=1
Durch das im FeldPassworteingegebene einfache Anführungszeichen läuft die Kontrolle der Übereinstimmung von Benutzername und Passwort darauf hinaus, dass überprüft wird, ob das Passwort des BenutzersMeierleer ist (passwort='') oder ob die Bedingung 1=1 zutrifft. Da beide Bedingungen oder-verknüpft sind, genügt es, wenn eine der beiden Bedingungen zutrifft. Dies ist für den Ausdruck 1=1 immer der Fall. Auf diese Weise wurde der Passwortschutz umgangen und der Angreifer kann sogar nicht nur auf alle Daten des BenutzersMeierzugreifen, sondern kann Einsicht in die Einträge aller Kunden erlangen. Es wird gar nicht erst überprüft, ob ein Benutzer namens „Meier“ überhaupt existiert, da der Ausdruck OR 1=1 die gesamte Where-Klausel als erfüllt kennzeichnet.
Neben der Ausspähung von Daten sind noch weit folgenschwerere Angriffe möglich. Die Eingabe von' OR 1=1; drop table kundendaten--als Passwort würde zu folgender Umsetzung durch das DBMS führen:
SELECT * FROM kundendaten WHERE benutzername='Meier' AND passwort='' OR 1=1; drop table kundendaten--
Hier zeigt sich eine weitere, sehr leicht auszunutzende Schwachstelle. SQL lässt mehrere Abfragen nacheinander zu. So wird durch die Einschleusung des gezeigten Codes in das SQLStatement erst eine vollkommen harmlose Abfrage ausgeführt und im Folgenden die Löschung einer kompletten Tabelle hervorgerufen.
Die beschriebenen Angriffszenarien sind bei nahezu jeder SQL-basierten Datenbank möglich. Einige Datenbanken bieten weitere Funktionalitäten, welche wiederum spezielle Angriffe ermöglichen. Eine solche Schwachstelle ist gegeben, wenn das Datenbanksystem eine Shell zu Administrationszwecken zur Verfügung stellt. Ist der Zugriff auf diese Shell nicht anständig geschützt, so kann ein Angreifer mit Leichtigkeit Zugriff auf das System erlangen. Falls die Kommandos „Select…into Outfile“oder „Select…into Dumpfile“unterstützt werden, können durch gezielte Manipulationen sogar Dateien auf dem Dateisystem des Datenbankservers abgelegt werden. Im weiteren Verlauf könnte dann beliebiger Code ausgeführt werden, um das System vollständig zu kompromittieren. Die dazu notwendigen Eingriffe sind jedoch schon weitaus komplexer, als die zuvor dargestellten Manipulationen der SQL-Statements und werden daher an dieser Stelle nicht weiter analysiert.
Weiterführende Informationen zu SQL-Injections finden sich zum Beispiel in [Friedl 2005]. Dort wird erläutert, mit welchen Methoden man zunächst die richtigen Spaltennamen in einer Tabelle und den Tabellennamen ermitteln kann, um im weiteren Verlauf einen eigenen Nutzer in das System einzutragen. Ziel des aufgezeigten Angriffszenarios ist es, sich später das Passwort des Administrators per E-Mail zuschicken zu lassen.
2.2.4 Maßnahmen zum Schutz des Datenbanksystems
Es hat sich gezeigt, dass diverse Sicherheitsvorkehrungen zum Schutz der Datenbank unverzichtbar sind. In Anlehnung an das KASIB soll im Folgenden aufgezeigten werden, welche Maßnahmen dafür in Frage kommen.
Grundsätzlich sollten, wie bei der Arbeit mit einem Betriebssystem, auch bei der Nutzung von Datenbanken stets Benutzer mit unterschiedlichen Zugriffsrechten angelegt werden. Bei Datenbanken wird unterschieden zwischen Zugriffsrechten lesender, ändernder, löschender und einfügender Art. Grundsätzlich sollte man Rechte immer so sparsam wie möglich vergeben. Insbesondere das Recht zur Weitergabe von Rechten an andere (GRANT TO) sollte sehr sorgfältig gehandhabt werden [BSI 2003]. Durch geschickte Rechtevergabe können Angreifer leicht in die Schranken gewiesen werden. Auch wenn es ihnen gelingt, in das System einzudringen, so haben sie wegen der eingesetzten Sicherheitsmechanismen nur sehr limitierte Möglichkeiten einen Schaden anzurichten. Sie haben zwar die Kontrolle über die Anwendung gewonnen, diese läuft bestenfalls jedoch nur mit eingeschränkten Rechten, was die Aktionsmöglichkeiten begrenzt. Gerade bei der Anwendung internetbasierter Hilfsprogramme zur Datenbankverwaltung wie PHPMyAdmin sind diese Vorsichtsmaßnahmen unbedingt zu beachten. Die Standard-Installation des Programms legt automatisch einen Nutzerrootohne Passwort, aber mit vollen Administratorenrechten an [Hahne 2003, S. 220]. Diese Konfiguration ist sicherheitstechnisch höchst kritisch und sollte umgehend durch die Vergabe geeigneter Benutzerrechte korrigiert werden (siehe dazu [Kofler 2001]). Es empfiehlt sich weiterhin, den Zugriff auf solche Programme zusätzlich passwortgesichert zu gestalten (siehe dazu [Hahne 2003, S. 223ff]).
2.2.5 Maßnahmen zum Schutz von PHP/ MYSQL -Anwendungen
Einige der aufgezeigten Angriffsszenarien basieren auf umfassenden Beeinflussungen der SQL-Statements. Die Einschleusung von bösartigem Code kann sehr leicht dadurch eingedämmt werden, dass man die Länge der möglichen Zeichen im Eingabefeld beschränkt. Es sollte schon zu Beginn der Entwicklungsphase analysiert werden, welche Daten später durch das Programm verarbeitet werden. Im gegebenen Szenario der onlinegestützten Klausuranmeldung wird beispielsweise die Matrikelnummer der Studierenden erfasst. Eine solche Matrikelnummer besteht an der Universität Hildesheim stets aus sechs Zahlen. Aufgrund dieser Kenntnis sollte das Eingabefeld auf sechs Ziffern beschränkt werden und in der Datenbank als DatentypIntegerangegeben werden:
Abbildung in dieser Leseprobe nicht enthalten
Quellcode-Beispiel 3: Definition des Eingabefeldes für die Matrikelnummer
Abbildung in dieser Leseprobe nicht enthalten
Abb. 3: Definition des Datenfeldes „ Matrikelnummer“ in der Datenbank
Wie durch die Hervorhebungen aufgezeigt, sollte die maximale Länge des Eingabefeldes stets der in der Datenbank definierten Größe des Datensatzes entsprechen. Auf diese Weise lassen sich größere Manipulationen auf sehr einfache Art und Weise verhindern. Ein Angreifer ist wegen der beschränkten Eingabelänge nicht in der Lage, längere Zeichenketten unterzubringen und umfangreiche Angriffe zu starten.
Wie in Abschnitt 2.2.3, Seite 14ff erläutert, müssen benutzerveränderbare Eingaben vor Ausführung der Datenbankoperationen auf mögliche ungültige Zeichen überprüft werden. Dazu bieten sich zwei verschiedene Ansätze. Die Skriptsprache PHP besitzt zur Maskierung von Eingabedaten die beiden Methoden:
1. string mysql_escape_string ( string unescaped_string )
2. string mysql_real_escape_string ( string unescaped_string [, resource Ergebnis-Kennung] )
Beide Funktionen arbeiten identisch, Letztere verarbeitet jedoch zusätzlich optional eine Verbindungs-Kennung [PHP Group 2003a, PHP Group 2003b]. Diese Vorgehensweise erfordert eine Menge sorgfältiger Zusatzarbeit des Programmierers, da er jede Benutzereingabe durch die genannten Funktionen überprüfen muss. SQL-Injections sind jedoch nicht mehr möglich. Die in Abschnitt 2.2.3, Seite 16 gezeigte Manipulation durch Eingabe vonMeierals Benutzername und' OR 1=1als Passwort ist durch die Maskierung des einfachen Anführungszeichens nicht mehr gefährlich. Das Datenbanksystem wird jetzt angewiesen dieses Zeichen als Teil des String mit in die Abfrage zu übernehmen:
SELECT * FROM kundendaten WHERE benutzername='Meier' AND passwort='\' OR 1=1'
Als Ergebnis sucht die Abfrage nun nach dem BenutzerMeiermit dem Passwort' OR 1=1. Auch die Aneinanderreihung mehrerer Abfragen ist nicht mehr möglich, da der erste Teil der Abfrage nicht mehr durch Benutzereingaben beendet und schadhafter Code als zweiter Abfrageteil untergeschoben werden kann. Betrachtet man die Vielzahl an Eingabefeldern im KASIB, so offenbart sich ein beträchtlicher Aufwand zur Behandlung aller Benutzereingaben. Eine weitaus weniger aufwendige Handhabe existiert auf einer anderen Ebene.
Alle Skripte werden serverseitig durch den PHP-Interpreter verarbeitet. Das KASIB soll später auf einem Apache-Server des Rechenzentrums der Universität Hildesheim laufen. Dieser bietet verschiedene Einstellungsmöglichkeiten, welche die Verarbeitungsroutinen des PHP-Interpreters betreffen. Bezogen auf die Verarbeitung von Benutzereingaben sind folgende zwei Werte von ausschlaggebender Bedeutung:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 4: Konfigurationseinstellungen des Apache Webservers, Rechenzentrum Universität Hildesheim
Die erste Anweisung bewirkt eine Kontrolle aller über $_GET, $_POST und Cookies übergebenen Variablen auf das Vorkommen von einfachen und „normalen“ Anführungszeichen sowie Backslashs. Werden solche Zeichen entdeckt, so werden sie mit einem Backslash escaped. Währendmagic_quotes_gpc den Datenaustausch zwischen verschiedenen Skripten überwacht, zielt die Anweisungmagic_quotes_runtime auf Funktionen innerhalb eines Skriptes ab. Funktionen, welche Daten aus externen Quellen wie Eingabefeldern, Datenbanken und Textdateien zurückgeben, dürfen keine der genannten Zeichen zurückliefern. Werden solche Zeichen in den übertragenen Daten entdeckt, so werden sie mit einem Backslash versehen [PHP-Center 2003]. Diese Sicherheitsmechanismen sind standardmäßig aktiviert und sollten von den Administratoren regelmäßig überwacht werden. Sie nehmen dem Programmierer eine Menge Arbeit ab und reduzieren die negativen Auswirkungen unsicher programmierter Software.
2.2.6 Bedrohungsszenario Cross-Site-Scripting
Da in PHP-Skripten auch Javascript-Code eingebettet werden kann, soll außerdem das Angriffsszenario des Cross-Site-Scripting, auch CSS10 oder XSS genannt, aufzeigt werden. Zunächst ist festzuhalten, dass es sich dabei nicht um ein browser- oder serverspezifisches Problem handelt. Man kann es nicht einmal direkt der Client- oder Serverseite einer Internetanwendung zuordnen. Es ist vielmehr ein „plattformübergreifendes Problem, das aus nicht vorhergesehenen Interaktionen zwischen komplexen, vernetzten Systemen resultiert“ [Woelfer 2004].
Ziel des Angriffs ist es, Informationen auszuspähen, auf die man eigentlich keinen Zugriff hat. Dazu lockt der Angreifer ahnungslose Nutzer über eine harmlos erscheinende URL auf eine manipulierte Seite. Die URL enthält bestimmte Parameter, die im Text der aufgerufenen Seite unmittelbar wiedergegeben werden. Enthält der Text bösartigen Javascript-Code, so wird dieser im Sicherheitskontext der Seite ausgeführt und der Angreifer kann nun z.B. Cookies auslesen, die von dieser Seite gesetzt wurden [Bachfeld 2003]. Hat sich der Angreifer dabei noch so geschickt angestellt, dass er alles in einem versteckten Frame ausführt, so wird der Betroffene meist nicht einmal bemerken, dass er ausspioniert wurde.
Um einem solchen Angriff zu begegnen, müssen sämtliche im Skript auszugebenden Variablen, insbesondere solche, die Benutzereingaben enthalten, speziell überprüft werden. Dazu wird die Funktion htmlentities() angewandt. Sie ersetzt Sonderzeichen durch ihre entsprechenden HTML-Codierungen [PHP Group 2003c]. Ziel ist es, die Ausgabe eines eventuell manipulierten Textes so umzugestalten, dass das enthaltene Javascript nicht ausgeführt werden kann. Ein Beispiel soll das Verständnis der theoretischen Ausführungen erleichtern. Betrachtet wird das Ergebnis der Ausführung schadhaften Codes jeweils mit und ohne Einsatz der htmlentities()-Funktion:
Abbildung in dieser Leseprobe nicht enthalten
Quellcode-Beispiel 4: Ausführung schadhaften Codes
Im ersten Beispiel werden die in der Variable $ausgabe gespeicherten Daten ohne weitere Überprüfung ausgegeben. Diese Nachlässigkeit führt zu folgendem Ergebnis:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 5: Ergebnis der Ausführung
Es wurde nicht erkannt, dass Javascript-Code eingeschleust wurde. Statt des hier zur Veranschaulichung erzeugten Hinweisfensters könnte beliebiger Javascript-Code zur Ausführung gebracht werden, über den der Angreifer in das System des Nutzers eindringen könnte. Der gewissenhafte Einsatz entsprechender Kontrollroutinen kann das Ausführen des Codes jedoch verhindern:
Abbildung in dieser Leseprobe nicht enthalten
Quellcode-Beispiel 5: Ausführung schadhaften Codes wird verhindert
Die Funktion htmlentities()wandelt jegliche Sonderzeichen zunächst in ihre HTMLÄquivalente um. Die interne Repräsentation des in der Variablen $ausgabe gespeicherten Stringinhalts sieht wie folgt aus:
<script> alert("Achtung Gefahr!"); </script>
Die Ausgabe durch den Browser führt wiederum zur Darstellung als String aus Buchstaben und Sonderzeichen. Es gelangt kein Javascript zur Ausführung:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 6: Ergebnis der Ausführung
Innerhalb von PHP-Skripten oder HTML-Seiten ist eingebettetes Javascript durch das öffnende Tag <script> gekennzeichnet. Dieses Tag wird nach Ende des Javascript-Codes wieder geschlossen (</script) und der Browser weiß, dass er nun wieder HTML-Code darstellen muss. Über die Anwendung von htmlentities() wird der Browser angewiesen, den Inhalt der jeweiligen Variablen als HTML zu interpretieren. So werden die den Javascript-Code umschließenden Tags nicht weiter beachtet und die Ausführung schadhaften Codes wird unterbunden.
2.2.7 Angriffsflächen bei der Übergabe von Variablen
Auf vielen Websites werden Daten immer noch durch die GET-Methode über die URL übergeben:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 7: Beispielhafte Übergabe von Daten über die URL
Diese Vorgehensweise birgt ein gewisses Risiko, da ein potentieller Angreifer so schon mehrere Informationen ermitteln kann. Das aufgerufene Skript scheint die Variablenstatus undusernamezu verarbeiten. Daraus schlussfolgernd liegt die Vermutung nahe, dass wohl auch in der Datenbank eine Spalteusernameexistieren könnte. Schon hat ein Angreifer wichtige Informationen, die er für eine SQL-Injection leicht ausnutzen kann. In Kombination mit einem weiteren Sicherheitsrisiko kann ein Angreifer sogar in der Lage sein, schadhaften Code beliebig nachzuladen. Viele PHP-Skripte arbeiten mit Seiten-IDs, welche für das Einfügen anderer Dateien sorgen. Über die ID weiß ein im Hintergrund arbeitendes Content Management System, welche Daten aus der im CMS erfassten Datenbasis eingefügt werden sollen. In PHP wird dies über den include()-Befehl realisiert. Die Anwendung zeigt an einer bestimmten Stelle im Quellcode auf eine Datei, deren Inhalt vom Skript dann an genau dieser Stelle nachgeladen wird. Diese Technik dient dazu, häufig genutzte Funktionen und Verarbeitungsroutinen auszulagern, um den eigentlichen Quellcode übersichtlicher zu halten. Sehr kritisch ist dieser Mechanismus, wenn die entsprechenden Daten über die URL übergeben werden. Folgende URL legt die Vermutung nahe, dass das Skriptstart.phpden Wert der Variablen$iddirekt als Pfad für den include()-Befehl übernimmt:
http://www.server.de/cms/start.php?id=info/termine.txt
Da der include()-Befehl komplette URLs verarbeiteten kann, bietet sich einem Angreifer die Möglichkeit, die URL so zu manipulieren, dass auch Daten von einem entfernten, nicht vertrauenswürdigen Server nachgeladen werden [1&1 Internet AG 2004]:
http://www.server.de/cms/start.php?id=http://www.angreifer.de/ hackcode.php
Für diese Angriffstechnik existieren inzwischen Anwendungen, die programmgesteuert Websites durchsuchen und auf ihre Verwundbarkeit testen. Hier sind die Administratoren der Webserver gefordert, Abhilfe zu schaffen. Die Lücke lässt sich einfach schließen. Der Eintrag vonallow_url_fopen_ = noin die Konfigurationsdateiphp.inischafft Abhilfe. Das Nachladen externen Codes wird so auf die eigene Domain, auf welcher die Skripte laufen, beschränkt [Henlein 2004]. Sofern der Server, der die Dateien hostet, gegen Angriffe von außen genügend geschützt ist, verlaufen alle Angriffsversuche erfolglos.
Grundsätzlich sollten gewissenhafte Programmierer vollständig auf die Datenweitergabe mit $_GET über die URL verzichten. Eine Option wäre die Weitergabe mittels $_POST, wobei die Daten zwar ebenfalls über die URL übergeben werden, aber nicht in der Adresszeile des Browsers sichtbar sind. Der Nachteil beider Mechanismen liegt allerdings darin, dass Daten nicht direkt über mehrere Skripte weitergereicht werden können. Eine Behelfslösung bietet der Einsatz von Hidden-Fields11.
Man sollte sich immer bewusst sein, dass über die URL übergebene Argumente beliebig vom Nutzer gesetzt werden können. Der Inhalt muss daher als nicht vertrauenswürdig eingestuft werden, ganz gleich, ob die Daten durch $_GET oder $_POST übergeben werden. Wenn man sich dieses Umstandes bewusst ist, sollte man daraus resultierend in den entwickelten Skripten konsequent jeden übergebenen Parameter durch jedes Skript neu prüfen [1&1 Internet AG 2004].
Einfacher ist es, das von PHP unterstützte Konzept der Sessions zu nutzen. Die Daten müssen nur einmal geprüft werden und können dann in einer Session gespeichert werden. Sie sind dann nicht mehr manipulierbar und können fortan als sicher eingestuft werden. Der Benutzer hat keine Möglichkeit, den Inhalt der Session direkt zu ändern [1&1 Internet AG 2004]. Eine Session lässt sich als eine Art Sitzung auffassen, bezogen auf eine Anwendungssoftware kann man damit die Kommunikation eines Nutzers mit einem Server beschreiben.
Eine Session beginnt mit dem Aufruf einer Website durch den Benutzer. Da auf einer Website gleichzeitig verschiedene Benutzer verweilen und mit dem dahinter stehenden Webserver interagieren können, wird für jeden Benutzer eine Sitzungs-ID generiert. Diese wird als Cookie auf dem Clientrechner gespeichert. Der Webserver legt für jede Sitzung eine Datei mit dem assoziativen Array $_SESSION an. Dabei handelt es sich um eine globale Variable, die jeder Website zur Verfügung steht und über die Daten ähnlich wie über $_GET und $_POST weitergereicht werden können. Sessionvariablen bestehen jedoch über die gesamte Lebensdauer der Session [Hahne 2003, S. 372ff]. Ein Variablenwert kann so nicht nur von der Folgeseite sondern durch alle vom Nutzer besuchten Seiten ausgelesen werden.
Zwar sind die Daten nur bei der Datenübergabe mittels $_GET in der Adresszeile des Browsers zu sehen, während bei Nutzung von $_POST die Angaben dort nicht sichtbar sind, jedoch basieren beide Übertragungsmechnismen ebenso wie das Sessionprinzip auf dem HTTP-Protokoll. Dieses Protokoll überträgt sämtliche Informationen im Klartext. Ein Angreifer kann mit Hilfe so genannter Sniffer12 an der Datenleitung lauschen und die Inhalte der übergebenen Variablen ohne große Mühe auslesen. Bei sehr sicherheitskritischen Anwendungsfällen wie dem Onlinebanking und dem Einkauf in Onlineshops kommen daher Verschlüsselungsmechanismen wie SSL zum Einsatz. Solcherart chiffriert übertragenen Daten können auch von mithorchenden Angreifern nicht decodiert werden.
3. Vorstellung des „KASIB“
Nach der Beschreibung der zu berücksichtigenden Umfeldfaktoren soll im Folgenden das Klausur-Anmelde-System des Instituts für Betriebswirtschaftslehre (KASIB) vorgestellt werden. Um die Leistungsfähigkeit der Anwendung beurteilen zu können, wird zuvor die bisher eingesetzte Lösung beschrieben. Im weiteren Verlauf wird darauf eingegangen, wie über das KASIB An- und Abmeldungen durchgeführt werden und welche weiteren Funktionen den Studierenden zur Verfügung gestellt werden. Die Arbeitsunterstützung im Verwaltungsbereich wird im dritten Abschnitt aufgezeigt.
3.1 Mängel der bisherigen Lösung
Das bisher vom Institut für Betriebswirtschaftslehre eingesetzte System bedient sich eines einfachen, in Frontpage13 erstellten Formulars und beinhaltet viele manuelle Arbeitsschritte, die automatisiert werden könnten.
Zunächst werden alle Klausurtermine gesammelt. Auf dieser Basis wird dann eine HTMLSeite mit den benötigten Formularelementen erstellt:
Abbildung in dieser Leseprobe nicht enthalten
Abb. 8: Formular zur Klausuranmeldung im Sommersemester 2004, Quelle: Website des Instituts für Betriebswirtschaftslehre
Die über die Formularfelder erfassten Eingabedaten werden in eine Textdatei geschrieben. Aus dieser Datei werden im weiteren Verlauf die Datensätze in eine Excel-Tabelle importiert. Die jeweiligen Klausurteilnehmer werden über Filter ausgelesen und auf Tabellenblätter kopiert. Für jede Klausur wird eine eigene Excel-Tabelle angelegt. Aus diesen einzelnen Tabellen werden abhängig von der Anzahl der benötigten Räume Tabellenblätter für den Klausuraushang erstellt. Weiterhin wird zu jeder Klausur ein Tabellenblatt mit Noten für das Sekretariatsarchiv und den Aushang erstellt.
Über das KASIB soll die Administration der Klausuranmeldungen wesentlich vereinfacht und oft durchgeführte Arbeitsschritte automatisiert werden. Der erste Ansatzpunkt bietet sich schon beim Export der Anmeldedaten. Diese werden nach Veranstaltungen getrennt direkt in eine Exceldatei geschrieben (vgl. Abschnitt 3.3.5, Seite 41). Auf diese Weise werden mehrere Arbeitsschritte des alten Systems in einer einzigen Funktion zusammengefasst. Schon in der Entwurfsphase wurde darauf geachtet, die neue Software von der Struktur her an das alte System anzulehnen. So fällt bisherigen Nutzern der Umstieg auf die neue Version leichter, als wenn bei der Entwicklung ein vollkommen andersartiger Ansatz gewählt worden wäre.
[...]
1 Klausur-Anmelde-System des Instituts für Betriebswirtschaftslehre
2 Schutz der Daten ist Datensicherheit.
3 Diese Vergabeweise teilt das Immatrikulationsamt auf Anfrage mit.
4 Eine robots.txt-Datei reglementiert die Indexierung einer Internetseite durch Suchmaschinen
5 CC = „Carbon Copy“: Alle Empfänger erhalten eine gleich lautende Kopie der Nachricht
6 BCC = „Blind Carbon Copy“: Jeder Adressat empfängt eine gleich lautende Kopie der Nachricht, ohne Kenntnis von weiteren Empfängern zu erhalten.
7 CERT steht fürComputer Emergency Response Team. Diese Organisation befasst sich mit Computersicherheit und gibt Warnungen vor Sicherheitslücken heraus.
8 Phishing bezeichnet den Versuch, durch verschiedene Maßnahmen in den Besitz von Informationen zu gelangen, mit der Absicht, sich finanzielle Vorteile zu verschaffen [Symantec 2004b].
9 Die laut dem Fortune-Magazin 100 größten Unternehmen der USA.
10 Hier steht die Abkürzung CSS für Cross-Site-Scripting, nicht zu verwechseln mit dem analogen Gebrauch von CSS zur Beschreibung von Cascading Style Sheets.
11 Nicht sichtbare Formularfelder, in welchen man Daten aus einem vorherigen Skript zwischenspeichern und an das Folgeskript weiterleiten kann. Jeder aktuelle Browser unterstützt jedoch das Anzeigen des WebseitenQuellcodes. In diesem sind die Hidden-Fields sichtbar, was ein Sicherheitsrisiko darstellt.
12 Sniffer sind spezielle Programme, die den Datenverkehr in einem Netzwerk mitlesen.
13 Frontpage ist ein Programm zur einfachen Erstellung von Internetseiten