Applikationssicherheit implementieren

Die meisten Angriffe auf Unternehmen laufen nicht über das Netzwerk, sondern über Fehler in Applikationen: ungeprüfte Eingaben, schwache Logins, fehlende Berechtigungsprüfungen. Du lernst die häufigsten Schwachstellenklassen kennen, probierst sie in einer bewusst verwundbaren Übungsumgebung selbst aus und behebst sie im eigenen Code. Dazu gehören sichere Anmeldung und Passwortspeicherung, saubere Zugriffskontrolle, der Umgang mit Geheimnissen und das Prüfen von Fremdbibliotheken. Am Ende kannst du eine Applikation systematisch auf Sicherheitslücken prüfen und deine Massnahmen begründen.

Das sind die Fähigkeiten, die am Ende des Moduls sitzen sollten. Jedes Ziel mit einem Beispiel aus dem Lehrbetrieb.

1. 1

   Bedrohungen für eine Applikation systematisch analysieren

   Kompetenz A

   Du schaust deine Applikation mit den Augen eines Angreifers an: Welche Daten sind wertvoll, wo kommen Eingaben herein, wo gibt es Vertrauensgrenzen? Daraus leitest du ab, welche Schwachstellen am wahrscheinlichsten und am gefährlichsten sind.

   Situation

   Eine Physiotherapie-Kette mit sieben Standorten lässt ein Patientenportal entwickeln, in dem Patienten Termine buchen und Befunde herunterladen.

   Deine Aufgabe

   Erstelle eine erste Bedrohungsanalyse vor dem Entwicklungsstart.

   Gutes Ergebnis

   Datenflussdiagramm mit Browser, API, Datenbank und Dateiablage. STRIDE-Tabelle mit 14 Bedrohungen, die drei kritischsten: Zugriff auf fremde Befunde über die URL, schwache Passwörter, ungeschützte Upload-Funktion. Für jede ist eine Massnahme im Backlog.

   Threat ModelingSTRIDEAngriffsflächeVertrauensgrenzeRisiko = Eintrittswahrscheinlichkeit x Schaden
2. 2

   Injection-Angriffe durch sichere Datenbankzugriffe verhindern

   Kompetenz B

   Du baust Eingaben nie direkt in SQL-, Shell- oder LDAP-Befehle ein. Stattdessen nutzt du Prepared Statements oder ein ORM und prüfst Eingaben zusätzlich gegen eine erlaubte Form. Du kannst eine SQL-Injection nachweisen und erklären, warum dein Fix wirkt.

   Situation

   Die Mitgliedersuche eines Sportvereinsverbands baut die Abfrage mit String-Verkettung zusammen. Mit der Eingabe ' OR '1'='1 erscheinen alle 4800 Mitglieder samt Adressen.

   Deine Aufgabe

   Weise die Lücke nach und schliesse sie.

   Gutes Ergebnis

   Die Abfrage nutzt jetzt ein Prepared Statement mit Platzhalter. Der gleiche Angriff liefert 0 Treffer. Ein automatisierter Test mit fünf typischen Injection-Eingaben verhindert, dass die Lücke zurückkommt.

   SQL-InjectionPrepared Statementparametrisierte AbfrageAllowlist-Validierung
3. 3

   Cross-Site Scripting und CSRF im Webfrontend abwehren

   Kompetenz B

   Du sorgst dafür, dass Benutzereingaben im Browser als Text und nicht als Code landen, setzt eine Content Security Policy und schützt zustandsändernde Anfragen gegen gefälschte Aufrufe von fremden Seiten.

   Situation

   Im Kommentarbereich eines Gemeinde-Mitwirkungsportals kann jemand ein Script einfügen, das Session-Cookies anderer Besucher abgreift.

   Deine Aufgabe

   Mach den Kommentarbereich sicher.

   Gutes Ergebnis

   Kommentare werden kontextgerecht escaped statt per innerHTML eingefügt. Cookies sind HttpOnly, Secure und SameSite=Lax. Eine CSP verbietet Inline-Scripts. Ein ZAP-Scan findet keine XSS-Meldung mehr.

   Stored / Reflected XSSOutput EncodingContent Security PolicyCSRF-TokenSameSite-Cookie
4. 4

   Anmeldung und Passwortspeicherung sicher umsetzen

   Kompetenz C

   Passwörter speicherst du nur als langsamen, gesalzenen Hash. Du schützt das Login gegen Durchprobieren, bietest Zwei-Faktor-Authentifizierung an und verwaltest Sessions oder Tokens so, dass sie nicht gestohlen oder ewig gültig sind.

   Situation

   Ein Online-Shop für Weine aus dem Wallis speichert Passwörter als MD5-Hash ohne Salt. Ein Angreifer hat in einem Forum eine Liste mit Hashes veröffentlicht.

   Deine Aufgabe

   Stelle die Passwortspeicherung um und härte das Login.

   Gutes Ergebnis

   Neue Passwörter werden mit Argon2id gehasht, bestehende beim nächsten Login migriert, alle Kunden müssen ihr Passwort zurücksetzen. Nach fünf Fehlversuchen greift eine wachsende Wartezeit, 2FA per Authenticator-App ist für Admins Pflicht.

   Hashing vs. VerschlüsselungSaltbcrypt / Argon2Brute Force / Rate LimitingZwei-Faktor-Authentifizierung
5. 5

   Zugriffskontrolle serverseitig konsequent durchsetzen

   Kompetenz D

   Du prüfst bei jeder Anfrage auf dem Server, ob die angemeldete Person diese Aktion auf genau diesem Datensatz ausführen darf. Fehlende oder nur im Frontend umgesetzte Prüfungen sind die häufigste Lücke in Webapplikationen.

   Situation

   Im Patientenportal kann man über '/api/befunde/1043' fremde Befunde herunterladen, indem man die Zahl ändert.

   Deine Aufgabe

   Schliesse die Lücke und sichere das ganze Portal ab.

   Gutes Ergebnis

   Jede Abfrage enthält die Patienten-ID aus dem Token als Filter. Fremde IDs liefern 404. Zusätzlich werden IDs als UUID statt fortlaufend vergeben, und ein Integrationstest pro Endpunkt prüft den Zugriff mit einem zweiten Testpatienten.

   Broken Access ControlIDORDeny by DefaultLeast PrivilegeRollen und Owner-Prüfung
6. 6

   Geheimnisse und Fremdbibliotheken sicher verwalten

   Kompetenz E

   API-Schlüssel, Datenbankpasswörter und Zertifikate gehören nicht in den Code oder ins Git-Repository. Du verwaltest sie über Umgebungsvariablen oder einen Secret-Store und überwachst die verwendeten Bibliotheken automatisch auf bekannte Schwachstellen.

   Situation

   Ein Lernender eines Elektrogrosshändlers hat den Zahlungs-API-Schlüssel versehentlich in ein öffentliches GitHub-Repository gepusht. Gleichzeitig nutzt das Projekt eine Logging-Bibliothek mit bekannter kritischer Lücke.

   Deine Aufgabe

   Behebe beide Probleme und verhindere Wiederholungen.

   Gutes Ergebnis

   Schlüssel sofort beim Zahlungsanbieter widerrufen und neu ausgestellt, Git-Historie bereinigt, Secret-Scanning aktiviert. Konfiguration über Umgebungsvariablen und Azure Key Vault. Dependabot erstellt jetzt wöchentlich Pull Requests für unsichere Abhängigkeiten.

   Secret ManagementUmgebungsvariablenKey VaultSoftware Composition AnalysisCVE
7. 7

   Eine Applikation auf Schwachstellen prüfen und Funde dokumentieren

   Kompetenz A

   Du kombinierst automatische Scanner mit gezielten manuellen Tests, bewertest die Funde nach Schwere und dokumentierst sie so, dass das Team sie priorisieren und beheben kann. Sicherheitsrelevante Ereignisse protokollierst du nachvollziehbar.

   Situation

   Vor dem Go-live des Patientenportals verlangt die Geschäftsleitung einen Nachweis, dass die gröbsten Lücken geschlossen sind.

   Deine Aufgabe

   Führe eine Sicherheitsprüfung durch und erstelle einen Kurzbericht.

   Gutes Ergebnis

   OWASP-ZAP-Scan, Semgrep-Analyse und eine manuelle Prüfung nach Checkliste. Bericht mit 9 Funden, davon 1 hoch (fehlender Rate Limit beim Passwort-Reset), 3 mittel, 5 tief, jeweils mit Nachweis, Risiko und Empfehlung. Login-Fehlversuche und Rechteänderungen werden neu protokolliert.

   DAST / SASTPenetrationstestSchweregrad (CVSS)Security LoggingSicherheitsbericht

Die Kompetenzmatrix zerlegt das Modul in Themenstränge und drei Stufen. Für den Kompetenznachweis solltest du überall mindestens Stufe 2 erreichen. Dein Stand bleibt in diesem Browser gespeichert und färbt Lernweg und Übungen ein.

Fabienne ist im 3. Lehrjahr als Informatikerin Applikationsentwicklung bei der Bödelisoft AG in Interlaken, die mit 50 Mitarbeitenden Software für Hotels entwickelt. Ein neues Gästeportal soll Buchungen anzeigen und Rechnungen als PDF bereitstellen, und in drei Wochen ist der Go-live geplant. Ihr Teamleiter gibt ihr den Auftrag, das Portal vorher auf Sicherheitslücken zu prüfen und diese zu beheben.

1. Kapitel 1

   Wer könnte was wollen?

   Fabienne zeichnet ein Datenflussdiagramm mit Gast, Portal, Buchungsdatenbank, Zahlungsanbieter und Hotel-Backoffice. Mit STRIDE kommt sie auf 14 Bedrohungen und bewertet jede nach Schaden und Wahrscheinlichkeit. Ganz oben landen fremde Rechnungen einsehen, Kontoübernahme und manipulierte Buchungsdaten. Diese drei Punkte prüft sie als Erstes.

   Ziel 1

2. Kapitel 2

   Ein Apostroph im Namen

   Ein Testgast namens D'Amico erhält bei der Suche eine Fehlermeldung mit SQL-Text, weil die Abfrage per String-Verkettung gebaut wird. Fabienne stellt alle Abfragen auf Prepared Statements um. Im Bemerkungsfeld einer Buchung speichert sie testweise ein Script-Tag, das im Backoffice tatsächlich ausgeführt wird. Sie ersetzt innerHTML durch escapende Templates, ergänzt eine Content Security Policy und schützt alle Formulare mit CSRF-Tokens.

   Ziel 2Ziel 3

3. Kapitel 3

   Login mit Ausdauer

   Fabienne entdeckt, dass Passwörter mit SHA-256 ohne Salt gespeichert sind. Sie stellt auf Argon2 um und hasht bestehende Passwörter beim nächsten erfolgreichen Login neu. Nach fünf Fehlversuchen gilt neu eine Sperre von 15 Minuten, und die Meldung lautet immer "E-Mail oder Passwort falsch", damit niemand testen kann, welche Adressen registriert sind. Zusätzlich bietet das Portal eine optionale Zwei-Faktor-Anmeldung an.

   Ziel 4

4. Kapitel 4

   Rechnung 4711 gehört nicht dir

   Mit Burp Suite ändert Fabienne in der Anfrage die Rechnungsnummer von 4711 auf 4712 und sieht die Rechnung eines fremden Gastes. Sie baut eine Besitzprüfung im Service ein und verankert sie zentral in einer Policy, statt sie in jeden Controller zu kopieren. Danach testet sie alle neun Endpunkte mit zwei Testkonten gegeneinander. Dabei findet sie zwei weitere Lücken beim PDF-Download und beim Stornieren, die sie ebenfalls schliesst.

   Ziel 5

5. Kapitel 5

   Der Schlüssel in der Historie

   Ein Scan mit gitleaks findet den API-Schlüssel des Zahlungsanbieters in einem Commit von vor acht Monaten. Fabienne lässt den Schlüssel sofort rotieren und legt den neuen im Secret-Store ab, und npm audit meldet drei kritische Lücken in der PDF-Bibliothek, die sie aktualisiert. Zum Abschluss lässt sie einen ZAP-Baseline-Scan und Semgrep laufen, sortiert neun von 23 Funden als Fehlalarme aus und begründet das jeweils. Ihr vierseitiger Bericht mit Ampelbewertung wird zur Grundlage für den Go-live-Entscheid.

   Ziel 6Ziel 7

1. 1

   Wie Angreifer denken

   ca. 4 Std.

   Du lernst die häufigsten Schwachstellenklassen kennen und analysierst eine Applikation auf Bedrohungen.

   • Die aktuellen OWASP Top 10 lesen und jede Kategorie mit einem eigenen Beispiel erklären
   • Für ein eigenes Projekt ein Datenflussdiagramm zeichnen und STRIDE anwenden
   • OWASP Juice Shop lokal mit Docker starten

   Trainiert Kompetenz A1A2

   Lernziel1

2. 2

   Eingaben, die zu Code werden

   ca. 6 Std.

   Du nutzt Injection und XSS in der Übungsumgebung selbst aus und behebst sie dann im eigenen Code.

   • Drei Juice-Shop-Aufgaben zu Injection und XSS lösen
   • Einen eigenen verwundbaren Endpunkt bauen, ausnutzen und mit Prepared Statements reparieren
   • Eine Content Security Policy für eine Beispielseite schreiben und im Browser testen

   Trainiert Kompetenz B1B2B3

   Lernziel23

3. 3

   Wer bist du, und was darfst du?

   ca. 7 Std.

   Du setzt sichere Anmeldung und konsequente Zugriffskontrolle um.

   • Passwortspeicherung mit bcrypt oder Argon2 umsetzen und Hashes vergleichen
   • Rate Limiting und 2FA für ein Login einbauen
   • Mit Burp Suite oder Postman IDs in Anfragen manipulieren und Lücken schliessen

   Trainiert Kompetenz C1C2D1D2

   Lernziel45

4. 4

   Geheimnisse und Lieferkette

   ca. 4 Std.

   Du räumst Konfiguration und Abhängigkeiten auf und automatisierst die Überwachung.

   • Ein Projekt nach Passwörtern und Schlüsseln im Code und in der Git-Historie durchsuchen
   • Konfiguration auf Umgebungsvariablen oder einen Secret-Store umstellen
   • Dependabot oder npm audit einrichten und einen Fund beheben

   Trainiert Kompetenz E1E2

   Lernziel6

5. 5

   Prüfen, bewerten, berichten

   ca. 5 Std.

   Du prüfst eine komplette Applikation und dokumentierst deine Funde professionell.

   • Einen ZAP-Baseline-Scan und eine Semgrep-Analyse durchführen und Fehlalarme aussortieren
   • Funde nach Schwere bewerten und einen zweiseitigen Sicherheitsbericht schreiben
   • Security-Logging für Login, Rechteänderungen und Fehler einbauen

   Trainiert Kompetenz A2A3

   Lernziel71

OWASP Top 10

Regelmässig aktualisierte Liste der wichtigsten Sicherheitsrisiken für Webapplikationen.

SQL-Injection

Angriff, bei dem Eingaben als SQL-Befehl interpretiert werden und so Daten gelesen oder verändert werden.

Cross-Site Scripting (XSS)

Einschleusen von Script-Code in eine Webseite, der im Browser anderer Benutzer ausgeführt wird.

CSRF

Cross-Site Request Forgery: Eine fremde Seite löst im Namen eines angemeldeten Benutzers ungewollte Aktionen aus.

Salt

Zufallswert, der vor dem Hashen an ein Passwort angehängt wird, damit gleiche Passwörter unterschiedliche Hashes ergeben.

Content Security Policy

HTTP-Header, der festlegt, aus welchen Quellen eine Seite Scripts, Styles und andere Ressourcen laden darf.

Threat Modeling

Strukturierte Analyse, welche Bedrohungen für ein System bestehen und wie sie abgewehrt werden.

CVE

Öffentliche Kennung für eine bekannte Sicherheitslücke in einer Software.

Passende Module