Mit Google fortfahren
Anwendungssicherheit: Risiken erkennen und verhindern
Anwendungssicherheit, kurz AppSec, schützt Software während ihres gesamten Lebenszyklus: vom Entwurf über Entwicklung und Tests bis zu Betrieb und Wartung. Dazu werden Risiken verhindert, Schwachstellen erkannt und Vorfälle behoben.
Auf dieser Seite lernst du, typische Schwachstellen zu analysieren, passende Kontrollen auszuwählen und Testverfahren sinnvoll zuzuordnen.
Hake ab, was du schon kannst — und komm am Ende hierher zurück!
Was muss eine sichere Anwendung schützen?
Stell dir eine Schulplattform vor: Lernende melden sich an, laden Dateien hoch und sehen ihre eigenen Ergebnisse. Eine sichere Anwendung muss dafür sorgen, dass nur berechtigte Personen auf die jeweiligen Daten und Funktionen zugreifen können.
Anwendungssicherheit
Anwendungssicherheit ist der fortlaufende Prozess, Sicherheitsrisiken in Software zu erkennen, zu verhindern und zu beheben. Sie umfasst sicheres Design, sichere Entwicklung, Tests, Überwachung und Wartung.
Drei grundlegende Schutzziele helfen bei der Planung:
- Vertraulichkeit: Daten sind nur für berechtigte Personen sichtbar.
- Integrität: Daten und Funktionen werden nicht unbefugt verändert.
- Verfügbarkeit: Die Anwendung und benötigte Daten bleiben nutzbar.
Dabei genügt es nicht, nur die Anmeldung zu schützen. Auch Eingaben, Rollen, Programmbibliotheken, Konfigurationen, Schnittstellen und der laufende Betrieb können Angriffsflächen bilden.
Ein Schüler darf seine eigene Bewertung lesen, aber nicht die Bewertungen anderer Personen verändern.
- Die Anmeldung prüft seine Identität.
- Die Zugriffskontrolle prüft bei jeder Anfrage seine Berechtigung.
- Die Protokollierung hält ungewöhnliche Zugriffsversuche fest.
Erst das Zusammenspiel dieser Maßnahmen schützt die Funktion angemessen.
Eine erfolgreiche Anmeldung beantwortet die Frage „Wer bist du?“. Die Autorisierung beantwortet bei jeder Aktion die andere Frage: „Was darfst du tun?“
Wie begleitet Sicherheit den Softwarelebenszyklus?
Sicherheit beginnt vor der ersten Codezeile. Wird sie erst am Ende geprüft, können grundlegende Architekturfehler bereits in vielen Funktionen stecken.
Ein sicherer Entwicklungslebenszyklus lässt sich so ordnen:
- Anforderungen festlegen: Welche Daten und Funktionen brauchen welchen Schutz?
- Bedrohungen modellieren: Welche Angriffswege sind denkbar, und welche Folgen hätten sie?
- Sicher entwerfen: Authentifizierung, Autorisierung, Verschlüsselung und Protokollierung in der Architektur einplanen.
- Sicher entwickeln: Eingaben korrekt behandeln, sichere Bibliotheken verwenden, Geheimnisse nicht im Code speichern und Code prüfen.
- Testen: Code, laufende Anwendung, Abhängigkeiten und Konfigurationen mit passenden Verfahren untersuchen.
- Sicher bereitstellen: sichere Einstellungen verwenden und unnötige Funktionen oder Debug-Schnittstellen entfernen.
- Überwachen und warten: Auffälligkeiten erkennen, Schwachstellen priorisieren, Updates einspielen und auf Vorfälle reagieren.
Shift Left bedeutet, Sicherheitsarbeit in frühe Phasen zu verlagern. Das ersetzt spätere Tests und Überwachung nicht. Es ergänzt sie, damit Fehler möglichst früh entdeckt werden.
Ein Team entwickelt eine Dateiablage.
- In der Anforderungsphase legt es fest, wer Dateien lesen, ändern und löschen darf.
- Beim Entwurf plant es Rollen und Prüfungen für jeden Zugriff.
- Während der Entwicklung behandelt es Dateinamen und andere Eingaben als nicht vertrauenswürdig.
- Vor der Bereitstellung testet es unzulässige Zugriffspfade.
- Im Betrieb überwacht es ungewöhnliche Abrufmuster und spielt Sicherheitsupdates ein.
So wird dieselbe Schutzidee in mehreren Phasen umgesetzt und überprüft.
Wie werden Schwachstellen zu kontrollierbaren Risiken?
Eine hilfreiche Analyse verbindet vier Fragen:
- Was ist die Schwachstelle?
- Wie könnte sie ausgenutzt werden?
- Welche Folge wäre möglich?
- Welche Kontrolle verhindert, erkennt oder behebt das Problem?
Beispiel: SQL-Injection
Bei einer SQL-Injection wird eine Eingabe so verarbeitet, dass sie die beabsichtigte Datenbankabfrage verändert. Das kann geschehen, wenn ein Programm Eingabetext direkt mit SQL-Befehlen zusammensetzt.
Unsicheres Prinzip:
Abfrage = "... WHERE name = '" + eingabe + "'"
Die Eingabe wird dabei wie ein Teil des Befehls behandelt. Eine manipulierte Eingabe kann deshalb die Bedeutung der Abfrage verändern.
Sicheres Prinzip:
Abfrage = "... WHERE name = ?" und Parameter = eingabe
Bei einer parametrisierten Abfrage bleiben SQL-Befehl und Eingabewert getrennt. Die Datenbankschnittstelle behandelt den Wert als Daten und nicht als nachträglich eingefügten SQL-Code.
Eingaben sind Daten, keine Befehle. Prüfe Eingaben zusätzlich auf zulässige Form und Länge, aber ersetze parametrisierte Abfragen nicht durch bloßes Filtern einzelner Zeichen.
Weitere typische Beziehungen sind:
| Schwachstelle | Mögliches Risiko | Passende Maßnahmen |
|---|---|---|
| Fehlerhafte Zugriffskontrolle | fremde Daten lesen, ändern oder löschen | Rollen prüfen, minimale Rechte vergeben, jeden Zugriff serverseitig autorisieren |
| Verwundbare Abhängigkeit | bekannte Lücke wird ausgenutzt | Komponenten erfassen, mit SCA prüfen, aktualisieren oder ersetzen |
| Fehlkonfiguration | unnötige Funktion oder Ressource ist erreichbar | sichere Voreinstellungen, Härtung, wiederholte Konfigurationsprüfung |
| Unzureichende Verschlüsselung | sensible Daten werden offengelegt | Daten bei Übertragung und Speicherung angemessen verschlüsseln |
| Fehlende Protokollierung | Angriffe bleiben unbemerkt | sicherheitsrelevante Ereignisse erfassen, auswerten und bei Auffälligkeiten warnen |
Welche Kontrollen und Tests ergänzen sich?
AppSec verwendet mehrere Schutzebenen, weil keine einzelne Maßnahme alle Fehler verhindert und erkennt.
Präventive Kontrolle
Eine präventive Kontrolle soll verhindern, dass eine Schwachstelle entsteht oder erfolgreich ausgenutzt wird. Beispiele sind parametrisierte Abfragen, minimale Berechtigungen und sichere Voreinstellungen.
Detektive Kontrolle
Eine detektive Kontrolle erkennt Schwachstellen, ungewöhnliches Verhalten oder Angriffsversuche. Dazu gehören Sicherheitstests, Protokollauswertung und Laufzeitüberwachung.
Korrektive Kontrolle
Eine korrektive Kontrolle behebt ein erkanntes Problem oder begrenzt dessen Folgen. Beispiele sind Updates, Patches, eine sichere Wiederherstellung oder das Zurücksetzen auf eine sichere Version.
Auch Testverfahren betrachten unterschiedliche Teile einer Anwendung:
| Verfahren | Was wird betrachtet? | Typischer Zeitpunkt oder Zweck |
|---|---|---|
| SAST | Quellcode oder Binärcode ohne Ausführung | frühe Suche nach Fehlern im Code |
| DAST | laufende Anwendung von außen | Verhalten unter simulierten Angriffen prüfen |
| IAST | laufende Anwendung mit interner Beobachtung | Laufzeitbefunde mit Codekontext verbinden |
| SCA | Bibliotheken und Drittanbieterkomponenten | bekannte Schwachstellen in Abhängigkeiten finden |
| RASP | Vorgänge innerhalb der laufenden Anwendung | bestimmte Angriffe zur Laufzeit erkennen und gegebenenfalls blockieren |
Ein Team möchte eine Webanwendung umfassender prüfen.
- SAST untersucht den Code früh auf unsichere Muster.
- SCA prüft die verwendeten Bibliotheken.
- DAST sendet Testanfragen an die laufende Anwendung.
- Nach der Bereitstellung überwachen Protokollierung und Laufzeitschutz verdächtiges Verhalten.
Die Verfahren ersetzen einander nicht, weil sie unterschiedliche Beobachtungsebenen haben.
Wie planst du Sicherheit für eine konkrete Anwendung?
Betrachte eine Anwendung, in der Lernende eigene Lösungen hochladen und Lehrkräfte Rückmeldungen vergeben. Gehe nicht sofort zu einem Werkzeug über, sondern beginne mit Daten, Rollen und möglichen Angriffswegen.
Schritt 1: Schutzbedarf bestimmen
Schützenswert sind unter anderem Konten, hochgeladene Lösungen und Rückmeldungen. Lernende sollen nur ihre eigenen Einreichungen sehen und verändern. Lehrkräfte benötigen weitergehende, aber ebenfalls begrenzte Rechte.
Schritt 2: Bedrohungen und Kontrollen verbinden
| Möglicher Fehler | Passende Kontrolle | Prüfung |
|---|---|---|
| Eingabe verändert eine Datenbankabfrage | parametrisierte Abfragen | manipulierte Eingaben in einer Testumgebung ausprobieren |
| Lernende öffnen fremde Einreichungen | serverseitige Autorisierung für jede Ressource | direkte Aufrufe mit verschiedenen Rollen testen |
| Veraltete Bibliothek enthält eine bekannte Lücke | Abhängigkeiten erfassen und aktualisieren | SCA und kontrollierter Update-Prozess |
| Ungewöhnlich viele Zugriffsversuche bleiben unbemerkt | Protokollierung, Überwachung und Warnungen | prüfen, ob Testereignisse erkannt werden |
Schritt 3: Ergebnisse bewerten
Ein bestandener Test beweist nicht, dass die gesamte Anwendung sicher ist. Er zeigt nur, dass eine bestimmte Kontrolle unter den geprüften Bedingungen funktioniert hat. Nach Änderungen müssen relevante Prüfungen wiederholt werden.
Fehlermeldungen sollten beim Testen ebenfalls geprüft werden. Sie müssen Nutzenden sinnvoll helfen, dürfen aber keine unnötigen internen Details oder Informationen über fremde Konten und Ressourcen offenlegen.
Karteikasten
Überlege zuerst selbst und drehe die Karte anschließend zum Prüfen um.
Alles auf einen Blick
- Anwendungssicherheit
- Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit
- Lebenszyklus: Anforderungen, Entwurf, Entwicklung, Test, Betrieb, Wartung
- Prävention: sichere Architektur, Eingabebehandlung, minimale Rechte
- Erkennung: SAST, DAST, IAST, SCA, Protokollierung
- Korrektur: Beheben, Patchen, Wiederherstellen
- Kontrolle: Maßnahmen wiederholt und unter realistischen Bedingungen prüfen
AppSec folgt damit einer wiederkehrenden Kette: Risiken verstehen, passende Kontrollen einbauen, ihre Funktion prüfen, den Betrieb beobachten und erkannte Probleme beheben.
Abschluss-Check
Wenn du bei einer Anwendung Schutzbedarf, Angriffsweg, Kontrolle und Prüfung miteinander verbinden kannst, analysierst du Anwendungssicherheit nicht als Werkzeugliste, sondern als durchgängigen Sicherheitsprozess.