Sicherheitsanalyse Webanwendung: Unterschied zwischen den Versionen
Kowa (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
|||
| Zeile 1: | Zeile 1: | ||
{{In Bearbeitung}} | {{In Bearbeitung}} | ||
=Definition= | ==Definition== | ||
Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben. | Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben. | ||
=Verfahren= | ==Verfahren== | ||
Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet. | Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet. | ||
=Beispiele= | ==Beispiele== | ||
Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet. | Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet. | ||
==M100 Data Validation: Filterung== | ===M100 Data Validation: Filterung=== | ||
Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil | Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil | ||
tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine | tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine | ||
| Zeile 20: | Zeile 20: | ||
==M110 Data Validation: Whitelisting statt Blacklisting== | ===M110 Data Validation: Whitelisting statt Blacklisting=== | ||
Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips: | Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips: | ||
| Zeile 29: | Zeile 29: | ||
der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen. | der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen. | ||
==M140 Data Validation: SQL-Injection verhindern== | ===M140 Data Validation: SQL-Injection verhindern=== | ||
Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter | Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter | ||
| Zeile 37: | Zeile 37: | ||
vom Input zur Ausführung gelangen können. | vom Input zur Ausführung gelangen können. | ||
==M150 Data Validation: Diverse Maßnahmen== | ===M150 Data Validation: Diverse Maßnahmen=== | ||
* Namen von Formularen überprüfen | * Namen von Formularen überprüfen | ||
* Länge/Größe der Eingabedaten begrenzen | * Länge/Größe der Eingabedaten begrenzen | ||
| Zeile 44: | Zeile 44: | ||
* Ausgabedaten filtern | * Ausgabedaten filtern | ||
==M170 Session Management== | ===M170 Session Management=== | ||
* SessionID nach Authentisierung erneuern | * SessionID nach Authentisierung erneuern | ||
| Zeile 50: | Zeile 50: | ||
* Session beenden | * Session beenden | ||
==Quellen== | |||
=Quellen= | |||
*[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen] | *[http://www.bsi.bund.de/literat/studien/websec/WebSec.pdf Sicherheit von Webanwendungen] | ||
Version vom 23. Mai 2019, 15:18 Uhr
Dieser Artikel wird derzeit von einem Autor gründlich bearbeitet. Die Inhalte sind daher evtl. noch inkonsistent.
Definition
Schwachstellen in Internetanwendungen sind heutzutage allgegenwärtig. Die große Vielfalt an Technologien in Verbindung mit der Struktur für eine Softwareanwendung im Internet bieten daher viele verschiedene Angriffsmöglichkeiten und Schwachstellen. Um das Potenzial so gering wie möglich zu halten, ist es wichtig keine offensichtlichen oder bekannten Fehler in den Algorithmen und Strukturen der Anwendung zu haben.
Verfahren
Basierend auf dem Maßnahmenkatalog „Sicherheit von Webanwendungen[2]“ des „Bundesamt für Sicherheit in der Informationstechnik“ (kurz BSI) kann eine Analyse der typischen Schwachstellen durchgeführt. Das Dokument beinhaltet einen sehr übersichtlichen Maßnahmenkatalog. Die einzelnen Maßnahmen müssen für die Analyse nach ihrer Relevanz für die Anwendung sortiert und gewertet.
Beispiele
Im folgenden sind ein paar Beispielmaßnahmen aus dem Katalog aufgelistet.
M100 Data Validation: Filterung
Alle Daten, die von außen in die Anwendung gelangen, sind zu validieren und zu fil tern. Neben den offensichtlichen Eingabedaten in Form-Variablen existieren eine Reihe weiterer Quellen. Ebenso sind Ausgaben an den Browser zu filtern, wenn dies nicht bereits durch die Inputfilterung mit abgedeckt ist. Der Abschnitt "Output Filte rung" geht auf diese Frage näher ein.
M110 Data Validation: Whitelisting statt Blacklisting
Eine grundsätzliche Entscheidung ist die Wahl des Validierungs- bzw. Filterprinzips: Blacklisting oder Whitelisting. Beim Blacklisting werden die Muster definiert, die aus dem Eingabestrom herausgefiltert werden, alles andere wird durchgelassen. Beim Whitelisting ist es umgekehrt: was nicht ausdrücklich erlaubt ist, ist verboten. Black listing ist dann problematisch, wenn als "nicht kritisch" erkannte Zeichen im Verlaufe der weiteren Verarbeitung zu einem ungewollten Systemverhalten führen.
M140 Data Validation: SQL-Injection verhindern
Durch Verwendung von Prepared Statements anstatt dynamisch zusammengebauter SQL-Statements kann dem Problem der SQL-Injection aus dem Weg gegangen wer den. Software-Entwickler müssen sich im Rahmen des Designs einer Funktion oder hat bzw. was die Menge aller möglichen Abfragestrukturen ist, die in Abhängigkeit vom Input zur Ausführung gelangen können.
M150 Data Validation: Diverse Maßnahmen
- Namen von Formularen überprüfen
- Länge/Größe der Eingabedaten begrenzen
- Serverseitig validieren
- Datentypen der Eingabedaten
- Ausgabedaten filtern
M170 Session Management
- SessionID nach Authentisierung erneuern
- Cookies einschränken
- Session beenden
