OWASP - User contributions [en]

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-03-28T08:34:56Z

Dennis Moers:

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 [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/org/owasp/esapi/Encoder.html API-Beschreibung der ESAPI] erklärt. Die Normalisierungs-Funktion ist allerdings schon vor einiger Zeit aus der ESAPI [https://lists.owasp.org/pipermail/esapi-dev/2010-January/000266.html 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, Dennis, .... <Dein Name>) ==
; Generell:
Reference auf RFCs fehlen.
tbd.

; Wortwahl:
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.
'''Hintergrundsystem:''' besseres Synonym?
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.
Bsp: "Erlangt ein Angreifer Kenntnis von einer solchen gültigen, aber nicht mehr genutzten SessionID, so kann er die Web-Anwendung im Sicherheitskontext des nicht abgemeldeten Benutzers weiter verwenden." (G 5,WA12 Unzureichendes Session-Management von Web-Anwendungen)
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.

== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==

Nachdem ich mir diese Gefährdung durchgelesen hatte, fehlten mir ehrlich gesagt etwas die Worte. Nicht nur, dass hier fast jeder zweite Satz entweder falsch ist bzw. massive Fehler enthält oder ich diesen schlicht nicht verstehe, ist der ganze Text sprachlich wirklich enorm verbesserungsfähig.

Na gut, ich konzentriere mich mal auf die fachlichen Punkte:

; 1. Security Controls
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.

; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"

Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt.

; 3. "Bei individuell entwickelten Web-Anwendungen sind im Allgemeinen die Frameworks, Komponenten und Schnittstellen im Rahmen der Konzeption auszuwählen und deren Einbindung und Absicherung zu betrachten....Im Gegensatz dazu ist bei der Konzeption von Web-Anwendungen auf Basis von Standardsoftware insbesondere auf die Auswahl der Software und die Konfiguration der Teilkomponenten zu achten"

Wir unterscheiden im Rahmen von Webanwendungen eigentlich Free or Opensource Software (FOSS bzw. FLOSS), Standardsoftware und Individualsoftware voneinander. Wir unterscheiden nicht Frameworks von Standardsoftware. Frameworks können Teil von Standardsoftware sein, wie etwa bei SharePoint, SAP, etc, oder aber FOSS, wie etwa Spring. Die ganzen Absätze machen für mich daher keinen Sinn.

; 4. "Eine Sicherheitsfunktion (z. B. Authentisierung, Autorisierung) wird nicht an einer Stelle umgesetzt und verwendet, sondern ist mehrfach in der Web- Anwendung realisiert. Wird diese Sicherheitsfunktion an den verschiedenen Stellen unterschiedlich umgesetzt, führt dies zu einem uneinheitlichen Sicherheitsniveau."

Natürlich ist die mehrfache Verwendung bestimmter Security Controls, beispielsweise von Zugriffskontrollen (Complete-Mediation) oder Validierung (Robustheit) erstrebenswert. Was der Autor hier wahrscheinlich meinte, war die Notwendigkeit diese zu Kapseln bzw. zu Externalisieren. Das bezieht sich im übrigen nicht nur auf die Controls selbst, sondern auch auf ihre Parametrisierung (etwa. über Konfigdateien / XACML).

Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.

; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"
Was will der Satz sagen? Ich wähle Standardsoftware aus, aber doch keine Webanwendungen. Oder heißt das, ich kaufe eine existierende Anwendung ein (Webanwendung!=Indivudualsoftware)?

; 6. "Das ausgewählte Produkt verfügt nicht über die ausreichende Sicherheitsfunktionalität, ... Daher müssen die notwendigen Schutzmechanismen nachträglich hinzugefügt werden, wodurch zusätzliche Aufwände entstehen."
Das ist etwas sehr positiv formuliert. Tatsächlich können fehlende Security Controls in zugekaufter Software (insb. Standardsoftware) in der Realität häufig gar nicht hinzugefügt werden oder nur perimetrisch (z.B. per WAF oder Access Gateway).

; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?

; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."
Was sind "schwache" Parameter?

Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?

; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"

Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?

Wie bereits bei den "Goldenen Regeln" angemerkt, gilt auch hier, das manche Security Controls auch clientseitig umgesetzt werden dürfen (etwa. zur Verhinderung von Dom-Based XSS).

== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis) ==
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."
Meiner Meinung nach passt in diesem Kontext die Attacke DoS nicht ganz. Falls die nachfolgende Funktionalität wegen der langen Ausführungszeit der Filterkomponente übersprungen wird bzw. ein Fehler auftritt würde dies meiner Ansicht in die Thematik Anwendungslogik passen. Eine DoS-Attacke kann hingegen anhand jeder Funktion durchgeführt werden.

== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==
; 1. "Ein Angreifer kann diese ausnutzen, um beispielsweise unbefugt Befehle an Hintergrundsysteme der Web-Anwendung zu übermittlen (z.B. in Form von Datenbankanfragen bei einer SQL-Injection)."
Umformulierung des Inhalts der Klammer. Hatte beim ersten Lesen für mich den Anschein, als ob ein Formular genutzt werden könnte welches den Nutzer aufforder eine SQLI einzugeben. Ich denke "Datenbankanfrage zwecks Ausführung einer SQL-Injection" würde besser passen.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-03-28T08:33:24Z

Dennis Moers:

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 [http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc4/org/owasp/esapi/Encoder.html API-Beschreibung der ESAPI] erklärt. Die Normalisierungs-Funktion ist allerdings schon vor einiger Zeit aus der ESAPI [https://lists.owasp.org/pipermail/esapi-dev/2010-January/000266.html 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.

== "G * Allgemein" (Dennis) ==
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.
'''Hintergrundsystem:''' besseres Synonym?
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.
Bsp: "Erlangt ein Angreifer Kenntnis von einer solchen gültigen, aber nicht mehr genutzten SessionID, so kann er die Web-Anwendung im Sicherheitskontext des nicht abgemeldeten Benutzers weiter verwenden." (G 5,WA12 Unzureichendes Session-Management von Web-Anwendungen)
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.

== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==

Nachdem ich mir diese Gefährdung durchgelesen hatte, fehlten mir ehrlich gesagt etwas die Worte. Nicht nur, dass hier fast jeder zweite Satz entweder falsch ist bzw. massive Fehler enthält oder ich diesen schlicht nicht verstehe, ist der ganze Text sprachlich wirklich enorm verbesserungsfähig.

Na gut, ich konzentriere mich mal auf die fachlichen Punkte:

; 1. Security Controls
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.

; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"

Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt.

; 3. "Bei individuell entwickelten Web-Anwendungen sind im Allgemeinen die Frameworks, Komponenten und Schnittstellen im Rahmen der Konzeption auszuwählen und deren Einbindung und Absicherung zu betrachten....Im Gegensatz dazu ist bei der Konzeption von Web-Anwendungen auf Basis von Standardsoftware insbesondere auf die Auswahl der Software und die Konfiguration der Teilkomponenten zu achten"

Wir unterscheiden im Rahmen von Webanwendungen eigentlich Free or Opensource Software (FOSS bzw. FLOSS), Standardsoftware und Individualsoftware voneinander. Wir unterscheiden nicht Frameworks von Standardsoftware. Frameworks können Teil von Standardsoftware sein, wie etwa bei SharePoint, SAP, etc, oder aber FOSS, wie etwa Spring. Die ganzen Absätze machen für mich daher keinen Sinn.

; 4. "Eine Sicherheitsfunktion (z. B. Authentisierung, Autorisierung) wird nicht an einer Stelle umgesetzt und verwendet, sondern ist mehrfach in der Web- Anwendung realisiert. Wird diese Sicherheitsfunktion an den verschiedenen Stellen unterschiedlich umgesetzt, führt dies zu einem uneinheitlichen Sicherheitsniveau."

Natürlich ist die mehrfache Verwendung bestimmter Security Controls, beispielsweise von Zugriffskontrollen (Complete-Mediation) oder Validierung (Robustheit) erstrebenswert. Was der Autor hier wahrscheinlich meinte, war die Notwendigkeit diese zu Kapseln bzw. zu Externalisieren. Das bezieht sich im übrigen nicht nur auf die Controls selbst, sondern auch auf ihre Parametrisierung (etwa. über Konfigdateien / XACML).

Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.

; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"
Was will der Satz sagen? Ich wähle Standardsoftware aus, aber doch keine Webanwendungen. Oder heißt das, ich kaufe eine existierende Anwendung ein (Webanwendung!=Indivudualsoftware)?

; 6. "Das ausgewählte Produkt verfügt nicht über die ausreichende Sicherheitsfunktionalität, ... Daher müssen die notwendigen Schutzmechanismen nachträglich hinzugefügt werden, wodurch zusätzliche Aufwände entstehen."
Das ist etwas sehr positiv formuliert. Tatsächlich können fehlende Security Controls in zugekaufter Software (insb. Standardsoftware) in der Realität häufig gar nicht hinzugefügt werden oder nur perimetrisch (z.B. per WAF oder Access Gateway).

; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?

; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."
Was sind "schwache" Parameter?

Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?

; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"

Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?

Wie bereits bei den "Goldenen Regeln" angemerkt, gilt auch hier, das manche Security Controls auch clientseitig umgesetzt werden dürfen (etwa. zur Verhinderung von Dom-Based XSS).

== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis) ==
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."
Meiner Meinung nach passt in diesem Kontext die Attacke DoS nicht ganz. Falls die nachfolgende Funktionalität wegen der langen Ausführungszeit der Filterkomponente übersprungen wird bzw. ein Fehler auftritt würde dies meiner Ansicht in die Thematik Anwendungslogik passen. Eine DoS-Attacke kann hingegen anhand jeder Funktion durchgeführt werden.

== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==
; 1. "Ein Angreifer kann diese ausnutzen, um beispielsweise unbefugt Befehle an Hintergrundsysteme der Web-Anwendung zu übermittlen (z.B. in Form von Datenbankanfragen bei einer SQL-Injection)."
Umformulierung des Inhalts der Klammer. Hatte beim ersten Lesen für mich den Anschein, als ob ein Formular genutzt werden könnte welches den Nutzer aufforder eine SQLI einzugeben. Ich denke "Datenbankanfrage zwecks Ausführung einer SQL-Injection" würde besser passen.

OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-03-28T07:54:00Z

Dennis Moers:

[[Category:OWASP_Project|OWASP Review BSI IT-Grundschutz Baustein Webanwendungen]]
==Mailing-List, Coordination and Contact==
If you want to become a part of the OWASP review team, please subscribe to the mailing list [https://lists.owasp.org/mailman/listinfo/bsi-webbaustein-review https://lists.owasp.org/mailman/listinfo/bsi-webbaustein-review]. It is not necessary to be a member to volunteer, of course :-)

The contact the coordinating team please mail to [mailto:bsi-webbaustein@owasp.de bsi-webbaustein@owasp.de] or contact the project leader [mailto:ralf.reinhardt@owasp.org Ralf] [[User:Ralf Reinhardt|Reinhardt]]

This is a project of the [[Germany | OWASP German Chapter]].

==Abstract==
Technical review of the module web application
("Baustein Webanwendungen") of the IT-baseline protection catalog ("IT
Grundschutz Katalog") of the German Federal Office for Information
Security ("BSI") from the OWASP's point of view.

==Introduction==
The German "Federal Office for Information Security" (BSI), which is
comparable to departments focused on security in organizations like NIST
or CCTA, offers the IT Baseline Protection ("IT-Grundschutz") for public
usage, which is based on ISO/IEC 27001. The IT Baseline Protection
include a catalog of approx. 80 "Bausteine" (building blocks). Those
blocks are dealing with one particular subject of IT security. They are
usually written in the German language and later translated to English.
They become the de facto standard for IT security and related
certifications in Germany after they are finally released.

In January 2012 the draft of the block "Webanwendungen" (web
applications) was released with a request for comments. Since this is
the core expertise of OWASP we invited a delegate of the BSI to attend
the last chapter meeting of the German Chapter which took place in
Frankfurt / Main on the 3rd of February. The meeting's outcome was the
strong wish to perform a review of that very web application block as an
OWASP project. This project will help to expand the visibility of OWASP
in the German IT security landscape broadly.

==Roadmap==
* Building a coordinating team
* <b>Defining the review rules</b> [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]]
* Reading the BSI documents
* Collecting comments from the community familiar with the BSI documents
* Creating a common understanding
* Writing a review with OWASP glasses
* Review of OWASP's review itself
* Releasing the result(s)

==Deadline==
06/01/2012, in German: '''01.06.2012'''

==Relevant links and general information==
==== Document download ====
"Entwurf Baustein Webanwendungen" of the BSI (in German language) directly:
[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Download/Vorabversionen/Baustein_Webanwendungen_Entwurf.zip https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/Download/Vorabversionen/Baustein_Webanwendungen_Entwurf.zip]

General download section of the BSI:
[https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/download/download.html https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/download/download.html]

==== Some further information about "BSI" and "Grundschutz"====
The BSI about itself: [https://www.bsi.bund.de/EN/Home/home_node.html https://www.bsi.bund.de/EN/Home/home_node.html ]

Wikipedia about BSI: [http://en.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik http://en.wikipedia.org/wiki/Bundesamt_f%C3%BCr_Sicherheit_in_der_Informationstechnik]

Wikipedia about "IT-Grundschutz Katalog": [http://en.wikipedia.org/wiki/IT_Baseline_Protection_Catalogs http://en.wikipedia.org/wiki/IT_Baseline_Protection_Catalogs]

==Actual Work in Progress==
Will be found in [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| "Discussion"]]. In German :-)

==Coordinating Team==
* Tobias Glemser
* Boris Hemkemeier
* Kai Jendrian
* Ralf Reinhardt
* Dirk Wetter

==Project Contributors==
* Dennis Moers
* ''Your name here''

==Project Licence==
Creative Commons Attribution ShareAlike 3.0