Difference between revisions of "Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen"

Revision as of 18:31, 26 March 2012

Since it's about a review of a document in German, all the discussions will be done in German :-)

Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)

Vorschlag für Kriterien, die an unser Review angelegt werden sollten (.kai)

• Der Baustein soll alle wichtigen Themen der Entwicklung sicherer

Webanwendungen enthalten.

• Der Baustein soll die verschiedenen Phasen der Software-Entwicklung

vollständig abdecken.

• Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und

unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein verbindliche Anforderungen auch tatsächlich stellen. Alle verbindlichen Anforderungen müssen unabhängig von der jeweiligen Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch sein.

• Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen

von OWASP im Widerspruch stehen.

• Die Maßnahmen sollen verständlich und anwendbar sein.

"Goldene Regeln" (Matthias)

Hier meine Anmerkungen zu diesem Dokument:

1. Für mich fehlende Punkte

• Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung
• Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip
• Bezug auf Defense-in-Depth-Prinzip
• Verwendung von getesteten Security APIs (z.B. OWASP ESAPI) statt selbstentwickelter Funktionen
• Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklerative vor programmatischer Sicherheit.

2. Begriff "Web-Anwendung"

Würde ich generell durch "Webanwendung" ersetzen.

3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")

Wozu dient dieser Satz?

4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....."

Ich fände es sinnvoller, wenn hier von der "Sicherheitsarchitektur" gesprochen wird, welche etwa neben den sicherheitsrelevanten Datenflüssen, sensible Komponenten, Entry Points, Akteure architekturelle Security Controls wie Authentisierung, Kryptographie und natürlich die Trust Boundaries beinhaltet.

5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."

Erstens würde ich hier den geläufigen Begriff "Individualsoftware" verwenden. Zweitens würde ich statt bestimmte SDLC-Phasen vorzugeben (die Begriffe "Softwareverteilung" und "Integration" sind mir bei Webanwendungen bisher noch nicht so häufig untergekommen), besser von der Notwendigkeit sprechen, Sicherheit in allen Entwicklungsphasen zu berücksichtigen, also eines SDLs.

6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."

Normalisierung ist für mich nicht gleich Kanonsierung, auch wenn beide Begriffe häufig als synonym verwendet werden. Der Unterschied wird in der API-Beschreibung der ESAPI erklärt. Die Normalisierungs-Funktion ist allerdings schon vor einiger Zeit aus der ESAPI rausgeflogen. Die generelle Kanonisierung von Ausgaben halte ich dazu für nicht sinnvoll.

Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt.

Besser fände ich hier Ein- von Ausgabevalidierung grundsätzlich voneinander abzugrenzen. Etwa was ich per Eingabevalidierung (Längenprüfung, Casting, etc. per Whitelisting) und was mit Ausgebavalidierung (Enkodierung, Escaping, Parametrisierung) machen muss und kann.

Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz?

7. "Für den Zugriff auf sensitive Funktionen oder Informationen muss die Web-Anwendung eine wirksame Authentisierung und Sitzungsverwaltung unterstützen. Die Eigenschaften der Sitzungs-ID müssen so gewählt werden, dass die Sitzung ausreichend geschützt ist. ...."

Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt."

Eigentlich geht es doch mehr um den Schutz der Sitzungs-ID, da diese gewöhnlich im Verlauf einer Sitzung den Client authentisiert. Oder den Schutz des Zugriffs auf eine Sitzung.

Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.

8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."

Dies würde ich nur auf sensible Daten beziehen. Zusätzlich zu HTTPS würde ich hier schreiben, dass sensible Daten generell nicht in der URL übertragen werden dürfen.

9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"

Hier würde ich eher schreiben "(IN Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"

10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."

Sprachlich: "Die Webanwendung muss sich stets in einem sicheren Zustand befinden. Beispielsweise müssen Fehler bei der Autorisierung zu einer Verweigerung des Zugriffs führen (Default-Deny-Strategie)."

11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."

Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.

Weiterhin sollten insbesondere beim Logging der Datenschutz berücksichtigt werden, personenbezogene Daten also nach Möglichkeit nicht oder nur anonymisiert in technischen Logdateien protokolliert werden.

12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."

Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert.

Überall dort wo der Client angegriffen wird, also etwa bei RIAs (Stichwort DOM-Based XSS) müssen wir Security Controls clientseitig implementieren. Es gibt mittlerweile deshalb auch eine Portierung der ESAPI auf Javascript. Überall dort wo der Server oder Hintegrundsysteme angegriffen werden, ist die Aussage aber natürlich zutreffend.

"Gefährdungen" (Markus, .... <Dein Name>)

Generell

Reference auf RFCs fehlen. tbd.