Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

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, Dennis, .... <Dein Name>)

Generell

Reference auf RFCs fehlen.

B.5.XX Web-Anwendungen

1. Erster Absatz - Letzter Satz

--Wieso werden hier nur HTML/XML Doks und Oberflächen angesprochen? Was ist der Unterschied zwischen einem HTML-Dok und einer Oberfläche? Was ist mit Flash, etc.? Was ist mit WebSockets?

2. Stichpunkt "Protokollierung"

Sicherheits relevant ist ein sehr dehnbarer Begriff - Eine bessere Formulierung könnte sein: Zur Rekonstruktion von Nutzerhandlungen nötige Ereignisse (positve & negative) müssen protokolliert werden . . .

3. Absatz

"Abgrenzung des Bausteins": "Die spez. Sicherheitsanforderungen an Web-Services werden in diesem Baustein nicht betrachtet" --> Wie so nicht? Was ist das Backend von einer Rest / AJAX-basierenden Webanwendung denn anderes als ein Web-Service? Diesen Satz würde ich entfernen.

4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur

5. Seite 4 

erste Zeile "Umsetzung": "dafür umzusetztende Komponenten müssen die Webanwendung schützen..." - Hier fehlt mir der Hinweis, dass dieser Schutz verifiziert werden muss.

6 Seite 5

"Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?

7 Seite 7

"Die Sicherheitsfunktion wird ausschließlich clientseitig..." --> Warum muss der Angreifer überhaupt einen Browser umkonfigurieren? Was ist mit Proxies, Scripts, etc.? Ich würde das reduzieren darauf, dass rein Webbrowser-basierende Schutzfunktionen einfach umgangen werden können.

8 Seite 8

Die angesprochenen Punkte hinterlassen den Eindruck nicht vollständig zu sein: Mir fehlen Punkte wie "Outsourcing", "KnowHow der Entwickler", Tooling, Framework-Auswahl, etc.

9 Seite 9

Eigentlich möchte der Autor hier über Datenschutz sprechen. Abgesehen von den letzten drei Zeilen geht es aber nur um "User tracking" - Wo ist der Rest der Datenschutzproblematik? Warum der Fokuss auf Tracking? Mir ist das zu einseitig.

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.

G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias)

Allgemein ist de obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?

Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:

• "Fehlendes Vorgehensmodell": Bezug auf fehlende Berücksichtigung von Sicherheit im SDLC. Statt eines SDLCs selbst sollte hier besser auf die Notwendigkeit eines Secure Development Lifecycle (SDL) hingewiesen werden
• "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"
• "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests).
• "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?

G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias)

Der Titel dieses Bausteines heißt "Schutz personenbezogener Daten", die genannten Beispiele beziehen sich bis auf den letzten jedoch auf die missbräuchliche (oder zumindest problematische) Nutzung aus Sicht des Datenschutzes.

Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:

• Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)
• Unsichere Einbindung von Werbeinhalten
• Unsichere Übertragung und Caching
• Unsichere Protokollierung
• Ungenügender Zugriffsschutz
• Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)

Auch wäre es ggf. zumindest einen Verweis auf das BDSG zu machen.

G 4.33 Unzureichende oder fehlende Authentisierung (Matthias)

1. Erster Absatz

"Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"

"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.

2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"

Hier findet nur ein Bezug auf "Passwörter" statt. Der Bezug auf die fehlerhaft implementierte oder dem Schutzbedarf ungenügende Schutzmechanismen (z.B. keine 2-Faktor-Authentisierung bei hochsensiblen Daten) fehlt. Auch auf das komplette fehlen von Authentisierungs-Controls wird hier nicht eingegangen

3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"

Wie bei 2., wird auch hier wieder nur auf Passwörter, nicht jedoch auf das fehlen von Controls selbst eingegangen. An dieser Stelle fehlt auch ein Hinweis auf die Notwendigkeit dedizierter Benutzeraccounts.

4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"

Statt untauglich würde ich auch hier von "dem Schutzbedarf der Daten nicht angemessen" sprechen, eigentlich gehört das für mich aber in die obigen Punkte.

5. Serverseitige Authentisierung fehlt

Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.

G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias)

1. "Unzureichende Validierung von Eingabedaten"

Die genannten Beispiele sind genau keine korrekten Beispiele für diesen Fall, sondern betreffen die Ausgabevalidierung bzw. Enkodierung. Typische Fehler der Eingabevalidierung ist eine Manipulierbarkeit der Business Logik.

2. "Unzureichende Validierung von Ausgabedaten"

Hier geht es zentral um die Verhinderung von Interpreter Injection, also serverseitig (z.B. SQL oder LDAP Injection) oder clientseitig (XSS, JSON Injection, etc.). Statt "können die Ausgaben Schadcode" enthalten würde ich hier eher davon Sprechen, dass ein solcher Interpreteraufruf manipuliert werden kann (was dann z.B. zur Einschleusung von Schadcode genutzt werden kann).

3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"

Mit ungenügender "Filterung" hat SQL Injection nichts zu tun, eigentlich geht es hierbei darum, dass SQL-Anfragen dynamisch mit unvalidierten Eingebedaten zusammengebaut (konkateniert) werden.

4. "Ungefilterter HTML-Code in Kommentar-Funktion"

Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.

G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias)

1. Erster Absatz

"Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."

Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".

2. "Beispiele"

Kommulierbarkeit

Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können

3. "Beispiele"

Gerichtsverwertbarkeit

Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.

G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias)

1. Titel

Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".

2. Beispiellink

Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.

3. Erster Absatz

"Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."

Interne Informationen auszublenden ist eine Härtungsmaßnahme, deren Anzeige erhöht aber nicht zwangsläufig die Wahrscheinlichkeit eines erfolgreichen Angriffs. Ich würde diesen Satz weglassen.

; 4. Fehlende Punkte

• Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.
• Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung

G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias)

1. Erster Absatz

"Können Funktionen einer Web-Anwendung ohne weitere Überprüfung der Authentizität des HTTP-Requests (z.B. durch Tokens in versteckten Formularfeldern) genutzt werden"

Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.

2. Dritter Absatz

"Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"

Dieser (Halb-)Satz macht keinen Sinn, auch weil es bei XSS nicht nur im Informationen auf dem Cient geht. Vorschlag: "ist das Angriffsziel nicht die Ausführung von Skriptcode, sondern von unbefugten, schreibenden Aktionen im Kontext des angemeldeten Benutzers."

3. Session Riding

Session Riding ist quasi nur ein anderer Begriff für CSRF. Die einzige Form von CSRF die mir bekannt ist, sind Angriffe mit Standard-Passwörtern auf HTTP-Basic-Auth geschützten Ressourcen.

Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.

4. Zum Beispiel

"Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."

Etwas ungüngstig ausgedrückt. Besser wäre: "wird eine Anfrage zur Änderung des Zugangspasswortes an den Router gesendet. Hierbei sendet der Browser automatisch den Session Cookie mit, worüber die Webanwendung die Authentizität der Anfrage verifiziert und die Änderung durchführt."

G 5.WA18 Clickjacking (Matthias)

Hier stellt sich mir nur die allgemeine Frage, ob Clickjacking, bzw. der Schutz davor tatsächlich einem Grundschutz zuzurechnen ist. Persönlich würde ich dies nicht tun.

M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias)

Verantwortlich für die Umsetzung

Hier wäre auch die Nennung des "Architekten" sinnvoll

Fehlende Bestandteile der Dokumentation

• Schutzbedarf des Systems sowie der verarbeiteten Daten
• Schützenswerte Daten und Funktionen (Assets)
• Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform
• Dokumentierte Konfigurationseinstellungen
• BIA (RTO, RPO)
• Schnittstellen
• Trust Boundaries
• Akteure (bzw. Trust Level)
• Sicherheitsannahmen
• Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)

Benutzermanagement

Wenn damit das Identity Management gemeint ist, gehört das Dokumentiert, ist aber keine Sicherheitsfunktion. Oder ist hiermit das Rollen- und Berechtigungskonzept gemeint? Grenzt sich aus meiner Sicht schwer mit dem Thema Authentisierung ab.

Prüffragen

Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"

M 2.WA24 Web-Tracking (Matthias)

Letzter Absatz

"Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "

Hier sollte denke ich besser von personenbeziehbaren Daten gesprochen Werten. Dies betrifft etwa die Zuordnung von Surfverhalten zu einer bestimmten Person. Dies sollte stets nach den Prinzipien Datensparsamkeit und Datenvermeidung, Erforderlichkeit, sowie Zweckbindung erfolgen. Ist Webtracking nicht personenbeziehbar ist dies kein Thema für den Datenschutz.

M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias)

Vermischung von Authentisierung und Session Management

Bei diesem Baustein findet eine ziemlich große Vermischung von Anforderung an die Authentisierung und das erst in "M 4.WA06 Session-Management bei Web- Anwendungen" behandelte Session Management statt (Beispiel: "Remember-Me-Funktion"). Beide Themen sollten sinnvollerweise getrennt voneinander zu betrachten und aufeinander zu beziehen.

Verwendung von Frameworks

Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)".

Remember-Me-Funktion

Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt.

Grenzwerte für gescheiterte Anmeldeversuche

Diese Empfehlung ist allgemein falsch, da sie sehr von der betrachteten Anwendung abhängt. Besser wäre hier allgemein von Mechanismen zur Verhinderung von automatisierten Angriffen zu sprechen (Anti-Automatisierung).

Etwa umsetzbar durch

• Sperrung nach x Anmeldeversuchen
• Throttling
• Captchas
• Sicherheitsfragen

Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.

Automatisiertes Zurücksetzen von Authentisierungsdaten

Würde ich besser als "Passwort-Reset" bezeichnen.

Weiterhin fehlt hier der Hinweis, dass statt ein automatisiertes Zurücksetzen, ein Mechanismus zu empfehlen ist, bei dem über ein hinterlegtes Sicherheitsmerkmal (Handy-Nummer oder E-Mail-Adresse) vom Benutzer zunächst eine Verifikation durchgeführt wird. Beispielsweise durch einen erhaltenen Link. Erst dann darf eine Änderung des Passwortes durch den Benutzer erfolgen.

Registrierung nicht behandelt

Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.

Verweis auf Externalisierung fehlt.

Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.

Verweis auf Behandlung von Credentials fehlt

Auch wenn das in "M 4.WA15 Schutz vertraulicher Daten bei Web- Anwendungen" ausführlich behandelt wird, sollte in diesem Baustein bereits auf den angemessenen Schutz von Authentisierungsdaten bei Übertragung und Speicherung hingewiesen werden.