Block 07 · IT-Sicherheit & Datenschutz – Lösungen

a) Zuordnung (4 P)

Zu 7: 20·19/2 = 190 ist die Formel für die paarweisen Schlüssel der symmetrischen Verschlüsselung.

b) Problem des eingebauten Schlüssels (2 P)

Alle installierten Apps hätten denselben Schlüssel. Ein Angreifer könnte ihn einmal aus der App auslesen (z. B. durch Analyse des Programmcodes) und damit den gesamten Datenverkehr aller Mitglieder entschlüsseln bzw. gefälschte Daten verschlüsseln. Außerdem lässt sich der Schlüssel praktisch nicht mehr austauschen, ohne alle Apps zu aktualisieren.

a) Ablauf der hybriden Verschlüsselung (6 P)

1. Die App baut die Verbindung auf; der API-Server sendet sein Zertifikat mit seinem öffentlichen Schlüssel.
2. Die App prüft das Zertifikat (CA-Signatur, Gültigkeit, Hostname).
3. Es wird ein zufälliger symmetrischer Sitzungsschlüssel erzeugt bzw. zwischen App und Server vereinbart. In der klassischen Darstellung erzeugt die App ihn und verschlüsselt ihn mit dem öffentlichen Schlüssel des API-Servers.
4. Der API-Server entschlüsselt den Sitzungsschlüssel mit seinem privaten Schlüssel. Nun kennen beide denselben Sitzungsschlüssel.
5. IBAN, Gesundheitsangaben und alle weiteren Nutzdaten werden mit dem Sitzungsschlüssel symmetrisch (z. B. AES) ver- und entschlüsselt.

b) Vorteile des hybriden Verfahrens (4 P)

• Gegenüber rein symmetrisch: Es ist kein vorheriger geheimer Schlüsselaustausch über einen sicheren Kanal nötig – der Sitzungsschlüssel wird sicher mit dem öffentlichen Schlüssel übertragen. (Das Schlüsselaustauschproblem entfällt.)
• Gegenüber rein asymmetrisch: Die großen Nutzdaten werden schnell symmetrisch verschlüsselt; asymmetrisch würde nur der kurze Schlüssel bearbeitet. Das Verfahren ist dadurch deutlich schneller und ressourcenschonender.

a) Was ist RSA? (3 P)

RSA ist ein asymmetrisches Verschlüsselungsverfahren mit einem öffentlichen und einem privaten Schlüssel (Schlüsselpaar). Seine Sicherheit beruht darauf, dass sich das Produkt zweier sehr großer Primzahlen praktisch nicht wieder in diese Faktoren zerlegen lässt. Es wird zum Verschlüsseln kleiner Datenmengen (z. B. eines Sitzungsschlüssels) und zum Erstellen digitaler Signaturen eingesetzt und arbeitet mit langen Schlüsseln (2048 Bit und mehr).

b) RSA für die Sensoren sinnvoll? (4 P)

Nein. Die PS-200 haben laut Anlage 3 nur einen 48-MHz-Mikrocontroller mit 32 KB RAM und keine Hardwareunterstützung für RSA. RSA ist sehr rechenaufwendig und würde die Batterie stark belasten (gefordert: mindestens 5 Jahre Laufzeit). Außerdem ist ein RSA-2048-Chiffrat mindestens 256 Byte groß, die Funkstrecke erlaubt aber nur 48 Byte je Nachricht. Die Aussage von Herrn Demir ist falsch: Asymmetrische Verfahren sind nicht grundsätzlich „sicherer“; AES-128 bietet vergleichbare Sicherheit, ist aber schnell und als Hardwarebaustein vorhanden.

c) Geeignetes Verfahren + Schlüsselverteilung (4 P)

Geeignet ist die symmetrische Verschlüsselung mit AES-128, die der PS-200 als Hardwarebaustein beherrscht. Jeder Sensor erhält bei der Produktion bzw. Inbetriebnahme einen eigenen, individuellen Schlüssel, der sicher im Sensor und auf dem Server hinterlegt wird. Schwachstelle der derzeitigen Lösung: Alle Sensoren eines Studios nutzen denselben gemeinsamen Schlüssel. Wird ein einziger Sensor ausgelesen oder entwendet, ist der Schlüssel aller Sensoren dieses Studios kompromittiert.

d) Transport- vs. Ende-zu-Ende-Verschlüsselung (4 P)

Bei der Transportverschlüsselung ist jede Teilstrecke für sich geschützt (Sensor → Gateway, Gateway → API-Server). Am Gateway liegen die Daten im Klartext vor, weil das Gateway sie entschlüsselt und neu verschlüsselt. Bei der Ende-zu-Ende-Verschlüsselung wären die Daten vom Sensor bis zum API-Server durchgehend verschlüsselt; das Gateway könnte sie nur weiterleiten, nicht lesen. Risiko der derzeitigen Lösung: Wer das Gateway kompromittiert oder physischen Zugang dazu hat, kann die Messwerte mitlesen oder verändern, bevor sie per TLS weitergehen.

e) Forward Secrecy (3 P)

Forward Secrecy (vorwärtsgerichtete Geheimhaltung) bedeutet: Selbst wenn ein Angreifer später den langfristigen privaten Schlüssel des Servers erbeutet, kann er zuvor mitgeschnittenen, verschlüsselten Datenverkehr nicht nachträglich entschlüsseln. TLS 1.3 erreicht das, indem für jede Verbindung ein temporäres (ephemeres) Schlüsselpaar per Diffie-Hellman verwendet und am Ende der Sitzung gelöscht wird. Das Sitzungsgeheimnis hängt damit nicht am dauerhaften Schlüssel des Servers.

a) Eigenschaften einer Hashfunktion (3 P)

Beliebige drei aus: Einwegfunktion (aus dem Hashwert kann man die Eingabe nicht zurückberechnen) · Kollisionsresistenz (praktisch keine zwei Eingaben mit gleichem Hashwert) · feste Ausgabelänge unabhängig von der Eingabegröße · Lawineneffekt (kleine Änderung → völlig anderer Hashwert) · deterministisch (gleiche Eingabe → gleicher Hashwert) · schnell berechenbar.

b) IBAN nur als Hash speichern? (3 P)

Der Vorschlag ist nicht umsetzbar. Ein Hashwert ist keine Verschlüsselung: Er ist eine Einwegfunktion und lässt sich nicht „entschlüsseln“. Die IBAN wird aber für die SEPA-Lastschrift wieder im Klartext benötigt, könnte dann also nicht mehr zurückgewonnen werden. Alternative: die IBAN verschlüsselt speichern (symmetrische Verschlüsselung der Datenbankfelder bzw. Festplattenverschlüsselung), sodass sie bei Bedarf wieder entschlüsselt werden kann.

a) Felder (1)–(6) (6 P)

b) Signatur ausreichend? (4 P)

Die Signatur stellt Integrität (jede Veränderung der Firmware fällt beim Vergleich auf) und Authentizität (die Firmware stammt nachweislich von Seidel & Brandt) sicher, zusätzlich Verbindlichkeit. Nicht gesichert wird die Vertraulichkeit – die Firmware wird im Klartext übertragen. Für Firmware-Updates ist das in der Regel ausreichend: Entscheidend ist, dass nur echte, unveränderte Firmware installiert wird; der Inhalt der Firmware ist nicht geheim. Eine Verschlüsselung ist also nicht zwingend nötig (kann den Schutz des Hersteller-Know-hows aber zusätzlich erhöhen).

a) Meldung „Unbekannter Herausgeber“ (4 P)

Die ausführbare Datei von PulsarDesk ist nicht digital signiert. Windows (SmartScreen) kann deshalb den Herausgeber nicht überprüfen und auch nicht ausschließen, dass die Datei auf dem Weg verändert wurde, und warnt vorsichtshalber. Abhilfe durch Code-Signing: Seidel & Brandt beschafft ein Code-Signing-Zertifikat einer anerkannten CA und signiert die Datei auf dem Build-Server mit dem zugehörigen privaten Schlüssel. Windows prüft dann die Signatur und die Zertifikatskette und zeigt den geprüften Herausgeber an; die Warnung entfällt.

b) Prüfung der Verbindung zum Web-Portal (5 P)

Der Server sendet beim Verbindungsaufbau sein TLS-Zertifikat. Der Browser prüft:

1. Stimmt der Name im Zertifikat (portal.pulsar-fitness.example) mit der aufgerufenen Adresse überein?
2. Ist das Zertifikat zeitlich gültig und nicht gesperrt (Sperrliste/OCSP)?
3. Ist die Signatur des Zertifikats korrekt? Sie wird mit dem öffentlichen Schlüssel der ausstellenden Zwischen-CA geprüft, deren Zertifikat wiederum mit dem der Root-CA – bis zu einem Root-Zertifikat, das im Vertrauensspeicher des Geräts liegt (Vertrauenskette).
4. Schließlich weist der Server über den Schlüsselaustausch nach, dass er den zum Zertifikat gehörenden privaten Schlüssel besitzt.

Erst wenn alle Prüfungen aufgehen, gilt die Gegenstelle als das echte Web-Portal (Schloss-Symbol); sonst erscheint eine Zertifikatswarnung.

c) „AES verhindert auch Veränderung“? (3 P)

Die Aussage ist falsch. AES (Verschlüsselung) sichert nur die Vertraulichkeit. Ein Angreifer kann das Chiffrat verändern, ohne den Schlüssel zu kennen; der Empfänger entschlüsselt dann veränderte oder unsinnige Daten, ohne es zu bemerken. Für den Schutz vor Veränderung braucht es zusätzlich einen MAC bzw. einen AEAD-Modus (z. B. AES-GCM) oder eine Signatur.

d) Manipulationserkennung ohne Signatur (4 P)

Geeignet ist ein MAC bzw. HMAC: Sensor und API-Server teilen einen geheimen (symmetrischen) Schlüssel. Der Sensor berechnet über die Messwerte mit diesem Schlüssel einen MAC und schickt ihn mit. Der Server berechnet den MAC über die empfangenen Werte mit demselben Schlüssel neu und vergleicht. Stimmen beide nicht überein, wurden die Daten verändert und werden verworfen. Ein MAC ist leichtgewichtig und daher für die rechenschwachen Sensoren geeignet (AES-basiert, z. B. AES-CMAC/GCM). Gleichwertig: AEAD-Modus, der Verschlüsselung und MAC kombiniert.

e) Warum keine Verbindlichkeit? (2 P)

Beim MAC kennen beide Seiten denselben geheimen Schlüssel. Der API-Server könnte einen gültigen MAC also selbst erzeugen und kann einem Dritten nicht beweisen, dass eine Nachricht wirklich vom Sensor stammt. Nur eine digitale Signatur mit einem privaten Schlüssel, den nur der Absender besitzt, ermöglicht diesen Nachweis.

a) Sicherheitsanforderungen aus A1–A3 (6 P)

b) Risiken veralteter Empfangs-PCs (4 P)

• Vertraulichkeit/Integrität: Für Windows 8.1 werden keine Sicherheitsupdates mehr veröffentlicht. Bekannt gewordene Lücken bleiben offen; Angreifer können die PCs übernehmen und auf Mitglieder- und Gesundheitsdaten zugreifen oder sie verändern (vgl. V13, Ransomware).
• Verfügbarkeit: Für das veraltete System fehlen Treiber, Ersatzteile und Unterstützung; aktuelle Software (PulsarDesk) läuft womöglich nicht zuverlässig, und bei einem Befall fällt der Empfangsbetrieb aus.

a) Schutzbedarfskategorien des BSI (3 P)

• normal: Die Schadensauswirkungen sind begrenzt und überschaubar.
• hoch: Die Schadensauswirkungen können beträchtlich sein.
• sehr hoch: Die Schadensauswirkungen können ein existenziell bedrohliches, katastrophales Ausmaß erreichen.

b) Schutzbedarf D1, D2, D3, D5 (8 P)

c) Schutzbedarf des Datenbank-Servers (2 P)

Hinsichtlich der Vertraulichkeit sehr hoch, da auf ihm auch die Gesundheits- und Körperdaten (D3) liegen. Dabei gilt das Maximumprinzip: Ein System erbt den höchsten Schutzbedarf der auf ihm verarbeiteten Daten bzw. Anwendungen.

d) Stellungnahme zu A4 (Backup) (3 P)

Die Aussage ist falsch. Ein Backup bleibt auch in der Cloud nötig. Die Redundanz des Anbieters (mehrere Festplatten, z. B. RAID) schützt nur vor Hardwaredefekten, nicht vor versehentlichem oder böswilligem Löschen, fehlerhaften Änderungen oder Ransomware – diese wirken sich auf alle Kopien gleichzeitig aus (vgl. V13). Es braucht regelmäßige, möglichst offline/unveränderbar gespeicherte Backups (3-2-1-Regel) und getestete Wiederherstellung; außerdem ist der Kunde datenschutzrechtlich selbst verantwortlich.

a) Authentifizierung vs. Autorisierung (2 P)

Authentifizierung ist der Nachweis der Identität: Die Trainerin meldet sich mit Benutzername und Passwort (und zweitem Faktor) an, das System prüft, wer sie ist. Autorisierung legt fest, was sie danach darf: Aufgrund ihrer Rolle darf sie die Körperdaten ihrer eigenen Mitglieder sehen, aber z. B. keine Tarife ändern.

b) Drei Faktorkategorien (3 P)

c) Passwort + Sicherheitsfrage (1 P)

Beides gehört zur Kategorie Wissen. Zwei Faktoren aus derselben Kategorie sind keine Zwei-Faktor-Authentifizierung; die Faktoren müssen aus verschiedenen Kategorien stammen.

a) Schwachstellen der Passwortspeicherung (4 P)

• MD5 ohne Salt: MD5 ist ein schneller, unsicherer Hash. Ohne Salt sind die Hashes für häufige Passwörter über vorberechnete Tabellen (Rainbow Tables) bzw. einen Wörterbuchangriff schnell aufzulösen (siehe Java-Ausgabe: hallo123, 123456, Sommer2025! gefunden).
• Gleiche Passwörter ergeben gleiche Hashes: Die Mitglieder 10231 (m.berger) und 10233 (k.hansen) haben denselben Hashwert 10b43971… – man erkennt sofort, dass sie dasselbe Passwort verwenden. Das wäre mit einem benutzerindividuellen Salt nicht sichtbar.

b) Speicherung in PulsarConnect (nach Anlage 10) (4 P)

Passwörter werden nie im Klartext gespeichert, sondern als Hashwert einer absichtlich langsamen Funktion (Argon2id, scrypt, bcrypt oder PBKDF2 mit vielen Iterationen). Vor dem Hashen wird jedes Passwort mit einem Salt kombiniert – einem mindestens 16 Byte langen Zufallswert, der für jeden Benutzer neu erzeugt und zusammen mit dem Hash gespeichert wird (nicht geheim); dadurch ergeben gleiche Passwörter verschiedene Hashes und Rainbow Tables werden nutzlos. Zusätzlich kann ein Pepper verwendet werden: ein geheimer, für alle Benutzer gleicher Wert, der nicht in der Datenbank steht (z. B. im Hardware-Sicherheitsmodul). Wird nur die Datenbank gestohlen, kann der Angreifer ohne den Pepper keine Passwörter durchprobieren.

c) Pseudocode pruefePasswort (4 P)

funktion pruefePasswort(eingabe : string, salt : string,
                        gespeicherterHash : string) : boolean
  h : string := sha256(PEPPER + salt + eingabe)      // 1. Durchlauf
  zähle i von 2 bis 10000                              // weitere 9 999 Durchläufe
    h := sha256(h + salt)
  Ende zähle
  wenn h = gespeicherterHash dann
    rückgabe true
  sonst
    rückgabe false
  Ende wenn
Ende funktion

Lauffähig als Java: java\07_IT-Sicherheit\Aufgabe_SEC_04_2.java (Methode pruefePasswort; enthält auch den Wörterbuchangriff aus a und die PBKDF2-Variante aus b).

Java · Aufgabe_SEC_04_2.java (Auszug)

static boolean pruefePasswort(String eingabe, String salt, String gespeicherterHash) {
    String h = sha256(PEPPER + salt + eingabe);          // 1. Durchlauf
    for (int i = 2; i <= 10000; i++) {                   // Durchläufe 2 bis 10 000
        h = sha256(h + salt);
    }
    return h.equals(gespeicherterHash);
}

Ausgabe (gekürzt)

m.berger  salt=3f9a1c0b...  hash=aecaf827...40e8dfc5
k.hansen  salt=c84e2b71...  hash=916d1c81...1419734c
Gleiches Passwort, verschiedene Hashwerte: true
pruefePasswort("hallo123", saltBerger, hashBerger) = true
pruefePasswort("Hallo123", saltBerger, hashBerger) = false
pruefePasswort("hallo123", saltHansen, hashBerger) = false  (falsches Salt)

a) Rollen und Inhalte (6 P)

Das mehrfach benötigte Element ist das Access Token: Es wird in Schritt ⑥ ausgestellt (B) und in Schritt ⑦ bei der Anfrage an die API mitgeschickt (C).

b) Vorteile von OAuth2 gegenüber Passwortweitergabe (4 P)

• Das Mitglied gibt sein Pulsar-Passwort nicht an die VitaKasse weiter; es meldet sich nur beim Pulsar-Login-Server an. Die VitaKasse kennt das Passwort nie und kann es nicht missbrauchen oder verlieren.
• Der Zugriff ist auf den Scope „Besuche lesen“ begrenzt und über ein Access Token mit Ablaufzeit geregelt; das Mitglied kann die Freigabe jederzeit einzeln widerrufen, ohne sein Passwort zu ändern. Bei Passwortweitergabe hätte die VitaKasse dagegen vollen Kontozugriff.

c) Single Sign-On – Vor- und Nachteil (4 P)

Vorteil: Die Mitarbeitenden müssen sich nur einmal anmelden und nur ein starkes Passwort (plus zentrale 2FA) merken; die Benutzerverwaltung ist zentral, beim Austritt wird ein Konto an einer Stelle gesperrt. Nachteil: Der Identitätsdienst ist ein Single Point of Failure – fällt er aus, ist keine Anmeldung mehr möglich; außerdem öffnet ein kompromittiertes Konto gleich alle angebundenen Systeme (daher 2FA zwingend).

d) Sicherer Passwort-Reset (4 P)

Schwachstelle: Der Reset hängt allein am E-Mail-Konto. Wer Zugriff auf das Postfach des Mitglieds hat (gehacktes oder mitgelesenes Konto, abgefangene Mail), kann über den Link sofort ein neues Passwort setzen und das Pulsar-Konto übernehmen. Sicherer: Es wird ein zufälliges, nur einmal verwendbares Token mit kurzer Gültigkeit (z. B. 30 Minuten) verschickt und zusätzlich ein zweiter Faktor über einen anderen Kanal verlangt (z. B. Code per SMS oder aus der Authenticator-App). Nach dem Reset werden alle Sitzungen beendet und das Mitglied benachrichtigt; es wird immer dieselbe neutrale Meldung angezeigt, egal ob die Adresse existiert.

a) Datenschutz vs. Datensicherheit (2 P)

Datenschutz schützt die Person und ihr Recht auf informationelle Selbstbestimmung: Er regelt, ob und wofür personenbezogene Daten verarbeitet werden dürfen (DSGVO). Datensicherheit schützt die Daten und Systeme selbst – alle Daten, nicht nur personenbezogene – vor Verlust, Manipulation und unbefugtem Zugriff (z. B. durch Verschlüsselung und Backups).

b) Personenbezogene Daten? (3 P)

1 und 6: über die Mitgliedsnummer ist die Person identifizierbar. 2: aggregiert/anonym. 4: kein Personenbezug. 3: die IP-Adresse gilt nach EuGH als personenbezogen.

a) Datenschutzmängel des Entwurfs (8 P)

Vier dieser Mängel genügen für die volle Punktzahl.

b) Inhalte der Datenschutzerklärung (2 P)

Zwei beliebige aus: Verantwortlicher (Kontaktdaten) · Zwecke und Rechtsgrundlagen der Verarbeitung · Empfänger/Weitergabe der Daten · Speicherdauer · Betroffenenrechte und Widerrufsrecht · Beschwerderecht bei der Aufsichtsbehörde.

a) Herzfrequenzdaten (3 P)

Herzfrequenz- und Gesundheitsdaten sind eine besondere Kategorie personenbezogener Daten (Art. 9 DSGVO). Ihre Verarbeitung ist grundsätzlich verboten und bedarf daher besonders strenger Voraussetzungen und eines hohen Schutzniveaus. Pulsar kann sie auf die ausdrückliche Einwilligung des Mitglieds stützen (Art. 9 Abs. 2 a).

b) Auskunft und Löschung (4 P)

Auskunftsrecht (Art. 15): Das Mitglied darf erfahren, welche Daten über es gespeichert sind, zu welchen Zwecken, an welche Empfänger und wie lange; es kann eine Kopie verlangen. Recht auf Löschung (Art. 17): Daten sind zu löschen, wenn der Zweck entfallen ist bzw. die Einwilligung widerrufen wurde. Aber: Die Rechnungsdaten unterliegen gesetzlichen Aufbewahrungspflichten (Handels-/Steuerrecht, mehrere Jahre). Solange diese laufen, dürfen bzw. müssen sie aufbewahrt werden; sie werden für andere Zwecke gesperrt statt gelöscht.

c) Cloud-Betrieb (3 P)

Der Cloud-Anbieter ist Auftragsverarbeiter. Pulsar muss mit ihm einen Vertrag zur Auftragsverarbeitung (AV-Vertrag) schließen, in dem Weisungsbindung und technisch-organisatorische Maßnahmen geregelt sind, und sich von dessen Sicherheitsmaßnahmen überzeugen. Da das Rechenzentrum in Frankfurt (EU) steht, ist das Datenschutzniveau gegeben; bei Servern außerhalb der EU wären zusätzliche Garantien (z. B. Standardvertragsklauseln) nötig.

d) Echte Daten in ein Online-Tool? (3 P)

Unzulässig. Mit dem Upload würden echte Namen und IBANs an einen Dritten übermittelt – ohne Rechtsgrundlage, ohne AV-Vertrag, ohne Kontrolle über Speicherort und -dauer (ggf. außerhalb der EU). Das verletzt den Datenschutz und die Vertraulichkeit (Objekt D2). Alternative: mit synthetischen Testdaten (erfundene, aber formal gültige IBANs) testen oder ein Prüfwerkzeug lokal im eigenen Netz einsetzen.

e) Privacy by Default (2 P)

Die datenschutzfreundlichste Einstellung ist die Voreinstellung. Beispiel: In der Mitglieder-App ist die Freigabe der Trainingsdaten an die VitaKasse standardmäßig deaktiviert und die Standortfreigabe aus; das Mitglied muss sie bewusst selbst einschalten.

a) Risiko (V3) (2 P)

Das Dokument enthält ein Makro. Wird „Inhalt aktivieren“ geklickt, führt es Programmcode aus und kann Schadsoftware nachladen und installieren (z. B. Ransomware, Spionageprogramm). Dokumente aus unbekannten externen Quellen sind deshalb besonders gefährlich.

b) Gegenmaßnahmen (2 P)

Zwei beliebige aus: Makros aus Internet-/Mail-Dokumenten per Richtlinie blockieren bzw. nur signierte Makros zulassen · Anhänge serverseitig filtern bzw. in einer Sandbox prüfen · aktuellen Virenschutz einsetzen · eingeschränkte Benutzerrechte · Mitarbeitende schulen.

c) Sicherere Alternative für eigene Rechnungen (2 P)

Rechnungen ohne aktive Inhalte versenden, z. B. als PDF, oder im Portal/in der App zum Abruf bereitstellen (Rückfragen über ein Formular dort). Begründung: Ein PDF bzw. die Anzeige im Browser/in der App enthält keine ausführbaren Makros; so gewöhnt Pulsar seine Mitglieder nicht daran, Makros zu aktivieren, und ein gefälschter Makro-Anhang fällt eher auf.

a) Sicherheitslücke in login (3 P)

SQL-Injection. Die Eingaben aus dem Feld „E-Mail“ werden in den Zeilen 13/14 per String-Verkettung direkt in den SQL-Text eingebaut. Enthält die Eingabe SQL-Sonderzeichen (z. B. ein Hochkomma), ändert sich dadurch die Bedeutung der Abfrage – ein Angreifer kann die Passwortprüfung umgehen oder weitere Daten auslesen.

b) SQL-Anweisung und Gefahr (4 P)

Für die gültige Adresse o'neil@mail.example und das Passwort Lauf2026 baut Zeile 13/14 folgende Anweisung:

SELECT mitglied_nr FROM mitglied
WHERE email = 'o'neil@mail.example' AND passwort_md5 = 'ac03ebddb7750a7c60020f0281650bd5'

Das zweite Hochkomma (in o'neil) beendet die Zeichenkette vorzeitig; der Teil neil@mail.example'… wird als SQL-Code gelesen und ergibt einen Syntaxfehler. Daran zeigt sich: Vom Benutzer gelieferter Text wird als SQL ausgeführt. Dieselbe Lücke lässt sich gezielt ausnutzen, um die Bedingung der WHERE-Klausel auszuhebeln und sich ohne gültiges Passwort anzumelden oder Daten auszulesen.

c) login mit PreparedStatement (5 P)

public boolean login(String email, String passwort) throws Exception {
    String sql = "SELECT mitglied_nr FROM mitglied WHERE email = ? AND passwort_md5 = ?";
    try (Connection con = DriverManager.getConnection(DB_URL, DB_USER, DB_PASS);
         PreparedStatement ps = con.prepareStatement(sql)) {
        ps.setString(1, email);                 // Eingaben werden nur als Daten übergeben
        ps.setString(2, md5(passwort));
        try (ResultSet rs = ps.executeQuery()) {
            return rs.next();
        }
    }
}

Lauffähig als Java: java\07_IT-Sicherheit\Aufgabe_SEC_06_3.java (Methoden loginNeu/loginSicher; mit optionalem H2-Treiber wird der Angriff gegen eine Testdatenbank gezeigt).

Ausgabe (Test gegen H2, Adresse mit Apostroph)

Fall                     loginUnsicher   loginSicher
richtiges Passwort       true            true
falsches Passwort        false           false
Adresse mit Apostroph    SQL-Fehler      true

Beim PreparedStatement wird die Abfrage mit Platzhaltern ? vorab an die Datenbank gegeben; die Werte werden anschließend getrennt als reine Daten übergeben und nie als SQL interpretiert. Die Adresse mit Apostroph wird dann korrekt verarbeitet.

d) Zwei weitere Mängel (4 P)

• Zugangsdaten im Quellcode (Zeilen 6–8): DB-URL, Benutzer root und Passwort stehen im Klartext im Code und werden mitversioniert. Abhilfe: Zugangsdaten auslagern (Konfiguration/Umgebungsvariablen/Secret-Store) und einen Datenbankbenutzer mit minimalen Rechten statt root verwenden.
• Technische Fehlermeldung an den Nutzer (Zeile 33): e.getMessage() wird in die Webseite ausgegeben und verrät interne Details. Abhilfe: dem Nutzer nur eine allgemeine Meldung zeigen, die Details serverseitig protokollieren.
• Gleichwertig anrechenbar: nicht geschlossene Verbindungen (Connection ohne try-with-resources, Ressourcenleck); ausgegebene Kommentare werden nicht HTML-kodiert (XSS in bewertungenAlsHtml).

e) Warum Client-Prüfung nicht reicht (2 P)

Prüfungen in App und Browser lassen sich umgehen: Ein Angreifer schickt seine Anfrage einfach direkt an den Server (z. B. mit einem eigenen Programm oder Werkzeug), ohne die App zu benutzen. Sicherheitsrelevante Prüfungen müssen daher immer auf dem Server erfolgen; das Prepared Statement wirkt dort unabhängig von der Eingabeprüfung.