OWASP - User contributions [en]

Category:OWASP Java Project

2012-09-30T20:46:50Z

Mrohr:

==== Main ====

The OWASP Java Project's goal is to enable Java and J2EE developers to build secure applications efficiently. See the [http://www.owasp.org/index.php/OWASP_Java_Project#tab=Roadmap OWASP Java Project Roadmap] for more information on our plans.

==Java Security Overview==

While Java and J2EE contain many security technologies, it is not easy to produce an application without security vulnerabilities. Most application security [[:Category:Vulnerability|vulnerabilities]] apply to Java applications just like other environments. The notable exception is [[Buffer Overflow|buffer overflow]] and related issues that do not apply to Java applications.

There is a wealth of information about vulnerabilities that apply to Java and JavaEE application in the [[:Category:Vulnerability|Vulnerability]] articles here at OWASP. The articles that have specific Java examples are tagged with the [[:Category:Java|Java category]].

The goals of this project are to provide information about building, configuring, deploying, operating, and maintaining secure Java applications. We cover the following topics:

; [[OWASP Java Table of Contents#J2EE Security for Architects | J2EE Security for Architects]]
: Provides information about the design and architectural considerations for a Java web application. Common architectures such as EJB, Web Services and Spring Middle tiers are discussed.

; [[OWASP Java Table of Contents#J2EE Security for Developers | J2EE Security for Developers]]
: These articles cover dangerous Java calls and common vulnerabilities associated with them, such as Runtime.exec(), Statement.execute(), readline(), etc... The dangers of native code, dynamic code, and reflection will be discussed. We'll also talk about using tools like PMD, jlint, FindBugs, Eclipse, jad, and more. This section will also cover standard security mechanisms in the JDK, such as cryptography, logging, encryption, error handling. Securing elements of an application, such as servlets, JSPs, controllers, business logic, and persistence layers will be covered. We'll discuss handling request parameters, encoding, injection, and more. We'll also discuss the use of security mechanisms such as log4j, BouncyCastle, XML encryption, XML signature, and other technologies.

; [[OWASP Java Table of Contents#J2EE Security For Deployers| J2EE Security for Deployers]]
: These articles cover topics specifically related to the J2EE environment. We discuss minimizing the attack surface in web.xml, configuring error handlers, and performing hardening of popular J2EE application servers.

; [[OWASP Java Table of Contents#J2EE Security for Security Analysts and Testers| J2EE Security for Security Analysts and Testers]]
: These articles cover the verification, analysis, and testing of the security of J2EE applications. This section will cover using tools to find vulnerabilities, both in source code and in running applications. These articles will focus on J2EE-specific aspects of testing applications that use various common J2EE frameworks and coding patterns.

==== Related OWASP Projects ====

;[[:Category:OWASP Enterprise Security API|OWASP Enterprise Security API (ESAPI) Project]]
:a free and open collection of all the security methods that a developer needs to build a secure web application.

;[[:Category:OWASP Guide Project|OWASP Development Guide]]
:a massive document covering all aspects of web application and web service security

;[[:Category:OWASP AntiSamy Project|OWASP AntiSamy Java Project]]
:an API for validating rich HTML/CSS input from users without exposure to cross-site scripting and phishing attacks

;[[OWASP Secure Coding Practices - Quick Reference Guide|OWASP Secure Coding Practices - Quick Reference Guide]]
:this document provides a quick high level reference for secure coding practices. It is technology agnostic and defines a set of general software security coding practices, in a checklist format, that can be integrated into the development lifecycle.

;[[:Category:OWASP Code Review Project|OWASP Code Review Guide]]
:a project to capture best practices for reviewing code.

;[[:Category:OWASP CSRFGuard Project|OWASP CSRFGuard Project]]
:a J2EE filter that implements a unique request token to mitigate CSRF attacks

==== Resources ====
<tbd>

==== Roadmap ====
The OWASP Java Project's overall goal is to...

build and maintain a central landing page on the Web for all Java users (developers, architects & co.) interested in Web security

and to

produce materials that show J2EE architects, developers, and
deployers how to deal with most common application security
problems throughout the lifecycle.

In the near term, we are focused on the following tactical goals:

# Restructure the existing content
# Align the page with other Java-related OWASP projects like ESAPI, Webgoat, ASVS (including a new chapter: "OWASP J2EE Related Projects")
# Priorize work on missing content
# Implement a J2EE/Java EE Secure Coding Guideline based on ESAPI, ASVS and/or the Quick Reference Guide.
# Set-up a comparision of security aspects of web frameworks such like struts2, spring mvc, jsf, gwt, etc.
# Set-up a comparision of security aspects of templating technologies such as jsp, velocity, tiles, etc.
# Provide examples of how to prevent comman attacks like XSS in popular web frameworks
# A practical guide to implementing a security policy for a Java web application
# Provide secure configuration guides for popular application servers
# Provide an OWASP Java Top 10

==Current Tasks==
* Call for volunteers - Join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list], read the [[Tutorial]], check the [[OWASP Java Table of Contents]] and get started!
* Review of current articles
See the [[OWASP Java Table of Contents]] for details of individual article status

==Ideas==

Please submit your high level ideas about the direction of the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this <nowiki>~~~~</nowiki>)
* To add specific articles, visit the [[OWASP Java Table of Contents]]

==== Project About ====
{{:Projects/OWASP Java Project | Project About}}

__NOTOC__
<headertabs/>

==Joining the Project==

[[user:Mrichter|Mirko Richter]] is the project lead. The project's high level roadmap can be found at the Roadmap tab.
* Please submit your ideas for individual articles to the [[Java Project Article Wishlist]].
* If you'd like to contribute:
# visit the [[Tutorial]],
# join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list]
# and pick a topic from the [[OWASP Java Table of Contents]], or suggest a new topic. 
Remember to add the tag: <nowiki>[[Category:OWASP Java Project]]</nowiki> to the end of new articles so that they're properly categorised.

[[Category:OWASP_Project| Java Project ]]
[[Category:OWASP Document]]
[[Category:OWASP Download]]
[[Category:Language]]

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T19:41:41Z

Mrohr: /* G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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, Matthias) ==
; 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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:56:48Z

Mrohr: /* "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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, Matthias) ==
; 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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:56:25Z

Mrohr: /* G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:56:06Z

Mrohr: /* M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:55:57Z

Mrohr: /* M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:55:46Z

Mrohr: /* M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:55:28Z

Mrohr: /* M 4.WA25Verhinderung von Clickjacking (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:55:17Z

Mrohr: /* M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:55:02Z

Mrohr: /* M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:54:13Z

Mrohr: /* "Hilfsmittel" (Markus) */

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.

== "Hilfsmittel" (Markus, Matthias) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:53:41Z

Mrohr:

[[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==
* Time is running out, so it's just: Review!
* Details [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]]


==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==

===Allgemeine Punkte===

[[OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen/Allgemeine_Punkte|Allgemeine Punkte]].

===Kapitel-Review===

Hier eine Auflistung der einzelnen Kapitel / Teile / Review-TODOs - wer einen Teil übernehmen möchte schreibt sich bitte einfach ein (im Feld Person).

Im Kommentarfeld bitte angeben, bis wann ihr plant, den Punkt fertig bearbeitet zu haben (und natürlich sonstige notwendigen Kommentare). Das Kommentarfeld eignet sich auch, um anzugeben, wer den peer review für diesen Teil macht (vgl. Status "in Diskussion").

Unter Status könnt Ihr das folgende angeben:
* offen (dieser Teil ist noch unbearbeitet)
* in Arbeit (dieser Teil wird aktuell bearbeitet)
* in Diskussion (Arbeit des initialen Reviewers abgeschlossen; Kommentierung / peer review durch andere wird durchgeführt)
* geschlossen (die Kommentierung dieses Teils ist abgeschlossen)
* übernommen (dieser Teil wurde in das finale Word-Dokument übernommen)

{| class="wikitable"
|-
! Kapitel / Teil
! Person
! Status
! Kommentar
|-
| B 5.XX Web-Anwendungen, Beschreibung und Abgrenzung (inkl. Seite 5)
| Markus
| in Diskussion
| keiner
|-

| G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-

| G 4.33 Unzureichende oder fehlende Authentisierung
| Matthias
| In Diskussion
| keiner
|-

| G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen
| Tobias
| In Diskussion
| keiner
|-
| G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-

| G 5.131 SQL-Injection
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 17
|-
| G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung
| unbekannt
| offen
| keiner, Seite 18
|-
| G 5.WA10 Fehler in der Logik von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA12 Unzureichendes Session-Management von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 21
|-
| G 5.WA13 Cross-Site Scripting (XSS)
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF)
| Matthias
| in Diskussion
| keiner
|-
| G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 25
|-
| G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 26 u. 27
|-
| G 5.WA17 Injection-Angriffe
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA18 Clickjacking
| unbekannt
| offen
| keiner, Seite 29
|-

| M 2.WA02 (B) Dokumentation der Architektur von Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-
| M 4.WA20 (A) Sicherer Entwurf der Logik von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 2.WA12 (B) Entwicklung und Erweiterung von Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA21 (A) Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA23 (A) Systemarchitektur einer Web-Anwendung
| Makrus
| in Diskussion
| keiner
|-
| M 2.WA24 (W) Web-Tracking
| Matthias
| in Diskussion
| keiner
|-

| M 4.WA04 (A) Authentisierung bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| M 4.WA05 (A) Umfassende Ein- und Ausgabevalidierung bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA06 (A) Session-Management bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA07 (A) Fehlerbehandlung durch Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA08 (B) Schutz vor automatisierter Nutzung von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA11 (A) Sichere Konfiguration von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA13 (A) Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA15 (A) Schutz vertraulicher Daten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA16 (A) Zugriffskontrolle bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA19 (B) Verhinderung von Cross-Site Request Forgery (CSRF, XSRF)
| Markus
| in Diskussion
| keiner
|-
| M 4.WA22 (B) Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen
| Markus
| In Diskussion
| keiner
|-
| M 4.WA25 (C) Verhinderung von Clickjacking
| Markus
| in Diskussion
| keiner
|-

| M 4.WA09 (C) Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 56 u. 57 u. 58
|-
| M 4.WA14 (A) Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| Dokument "Webanwendungen_Goldene Regeln.pdf"
| Matthias
| In Diskussion
| keiner
|-
| Dokument "Webanwendungen_Hilfsmittel.pdf"
| Markus
| in Diskussion
| keiner, 3 Seiten
|-
| Dokument "Webanwendungen_Kreuzreferenztabelle.pdf"
| unbekannt
| offen
| keiner, 2 Seiten
|-
|}
Weitere Informationen und die aktuellen Arbeitsstände gibt es unter [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| "Discussion"]].

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

==Project Contributors==
* Dennis Moers
* Markus Miedaner
* [[User:Mrohr|Matthias Rohr]]
* ''Your name here''

==Project Licence==
Creative Commons Attribution ShareAlike 3.0

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:52:52Z

Mrohr:

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

([[User:Mrohr|Matthias]]) Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

([[User:Mrohr|Matthias]]) Special Character bzw. DB Escaping ist schon recht DB-spezifisch (siehe [https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet SQL Prevention Cheat sheet]). Wozu werden die hier ueberhaupt aufgefuehrt? Um Eingebafilterung nach pot. SQL Injections durchzufuheren, oder um eine eigene Escaping-Funktion zu schreiben? Raus damit!

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:44:58Z

Mrohr:

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

== Hilfsmittel zur Nutzung des Bausteins B 5.XX Web-Anwendung (Matthias) ==

Die Formel zur Berechnung der Entropie von Session IDs kann ich persoenlich nicht bewerten.

Verwunderlich finde ich aber, dass der Autor zum Einen zwar von der Verwendung von JavaScript vollstaendig abraet, zum Anderen aber eben solches als Best-Practice-Ansatz fuer Click Jacking empfiehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T15:10:09Z

Mrohr: /* M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren

; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
([[User:Mrohr|Matthias]]) Ich glaube hier ist es wichtig zu unterscheiden, wo die Fehlermeldung ausgegeben bzw. wem diese angezeigt wird. Das wird in diesem Modul garnicht so recht unterscheiden. Der Autor meint glaube ich, wie Fehlermeldungen durch die Webanwendung angezeigt werden. In dem Fall hat er recht. Du meinst glaube ich eher, wie Fehlermeldungen protokolliert werden. In dem Fall hast du natuerlich auch recht. Das in dem Text verwendete Wort "ausgeben" ist nicht unbedingt eindeutig und sollte genauer spezifiziert werden.

; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
([[User:Mrohr|Matthias]]) Stimmt, wobei sich diese ja auch nur auf einen sehr bestimmten Fehlertypen beziehen. Generell laesst sich so etwas unterscheiden, wenn man Fehler-Domains erstellt. Beispiel: Technisch-Unerwartet = Abbruch, Technisch-Erwartet = Fehlermeldug/Tear Pit, etc.

; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.
([[User:Mrohr|Matthias]]) Hm, der Aussage kann ich nicht ganz zustimmen, bzw. es haengt von dem Begriff "Komponente" ab. Eine Anwendungskomponente kann serwohl bewusst bestimmte Exceptions werfen, die von der einbindenden Komponente behandelt werden muessen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:33:36Z

Mrohr: /* M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
([[User:Mrohr|Matthias]]) Stimmt, habe das Dokument mal komplett durchgesucht.Tatsaechlich wird der "Architekt" niemals genannt, das scheint also eher ein grundseatzliches Problem zu sein. Der Administrator hat hier aber nun wirklich nichts zu suchen.

; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:29:29Z

Mrohr: /* "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.

([[User:Mrohr|Matthias]]) Jo stimmt, aber ich stimme mit der Aussage eigentlich schon ueberein, auch wenn diese zugegeben etwas ungluecklich formuliert ist. Es geht hier ja darum, rechenintensive Pruefungen/Filterung moeglichst zu vermeiden bzw. zu reduzieren. Aus diesem Grund machen wir ja auch bei der AV-Pruefung zunaechst Blacklist-Checks und erst am Ende rechenintensive statistische oder verhaltensbezogene Pruefungen.

== "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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:24:36Z

Mrohr: /* M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:24:20Z

Mrohr: /* M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:24:05Z

Mrohr: /* M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:22:34Z

Mrohr: /* M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

([[User:Mrohr|Matthias]]) Von mir schon;)

; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:21:30Z

Mrohr: /* M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:21:13Z

Mrohr: /* M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.

([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:

Cache-control: no-cache, no-store
Pragma: no-cache
Expires: -1

([[User:Mrohr|Matthias]]) Die Empfehlung hinsichtlich des manuellen Leerens des Browsercaches sollte wenn dann nur bei Anwendungen mit sehr hohem Schutzbedarf in Erwaegung gezogen werden. Wichtiger waere da schon eher die richtigen Cache-Header zu verwenden. Solche Empfehlungen ihm Rahmen des Grundschutzes aber wirklich nichts zu suchen.

; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T13:13:07Z

Mrohr: /* M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.

([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?

; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.
Nein, das ist leider total falsch. Das Domain-Attribut stellt eine Aufweichung der Cookie-Gueltigkeit dar und nicht anders herum. Gewoehlich sind Cookies immer Host-Cockies und das sollte auch so bleiben. Die Empfehlung sollte entfernt werden.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T11:41:25Z

Mrohr: /* M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
([[User:Mrohr|Matthias]]) Am Besten Referenz auf [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html]

; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
([[User:Mrohr|Matthias]]) Es ist sicher nicht die schoenste Variante, es laesst sich aber nunmal in vielen Faellen nicht vermeiden. Deshalb fordert der [http://code.google.com/p/owasp-asvs/wiki/Verification_V2 ASVS] hier etwa auch nicht mehr. Fuer den hier angestreben Grundschutz sollte das meiner Meinung nach ausreichen.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu

([[User:Mrohr|Matthias]]) Weiterhin, fehlt ein genereller Bezug auf HTML 5 WebStorage, LSOs etc. Zumindest in abstrakter Form, so dass diese dadurch indirekt addresiert werden. Egal, in dem relevanten Punkt will der Autor meiner Meinung nach nur einige Beispiele nennen, das sollte keinen Anspruch auf Vollsteandigkeit haben muessen.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T11:21:14Z

Mrohr: /* Kapitel-Review */

[[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==
* Time is running out, so it's just: Review!
* Details [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]]


==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==

===Allgemeine Punkte===

[[OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen/Allgemeine_Punkte|Allgemeine Punkte]].

===Kapitel-Review===

Hier eine Auflistung der einzelnen Kapitel / Teile / Review-TODOs - wer einen Teil übernehmen möchte schreibt sich bitte einfach ein (im Feld Person).

Im Kommentarfeld bitte angeben, bis wann ihr plant, den Punkt fertig bearbeitet zu haben (und natürlich sonstige notwendigen Kommentare). Das Kommentarfeld eignet sich auch, um anzugeben, wer den peer review für diesen Teil macht (vgl. Status "in Diskussion").

Unter Status könnt Ihr das folgende angeben:
* offen (dieser Teil ist noch unbearbeitet)
* in Arbeit (dieser Teil wird aktuell bearbeitet)
* in Diskussion (Arbeit des initialen Reviewers abgeschlossen; Kommentierung / peer review durch andere wird durchgeführt)
* geschlossen (die Kommentierung dieses Teils ist abgeschlossen)
* übernommen (dieser Teil wurde in das finale Word-Dokument übernommen)

{| class="wikitable"
|-
! Kapitel / Teil
! Person
! Status
! Kommentar
|-
| B 5.XX Web-Anwendungen, Beschreibung und Abgrenzung (inkl. Seite 5)
| Markus
| in Diskussion
| keiner
|-

| G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-

| G 4.33 Unzureichende oder fehlende Authentisierung
| Matthias
| In Diskussion
| keiner
|-

| G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen
| Tobias
| In Diskussion
| keiner
|-
| G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-

| G 5.131 SQL-Injection
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 17
|-
| G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung
| unbekannt
| offen
| keiner, Seite 18
|-
| G 5.WA10 Fehler in der Logik von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA12 Unzureichendes Session-Management von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 21
|-
| G 5.WA13 Cross-Site Scripting (XSS)
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF)
| Matthias
| in Diskussion
| keiner
|-
| G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 25
|-
| G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 26 u. 27
|-
| G 5.WA17 Injection-Angriffe
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA18 Clickjacking
| unbekannt
| offen
| keiner, Seite 29
|-

| M 2.WA02 (B) Dokumentation der Architektur von Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-
| M 4.WA20 (A) Sicherer Entwurf der Logik von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 2.WA12 (B) Entwicklung und Erweiterung von Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA21 (A) Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA23 (A) Systemarchitektur einer Web-Anwendung
| Makrus
| in Diskussion
| keiner
|-
| M 2.WA24 (W) Web-Tracking
| Matthias
| in Diskussion
| keiner
|-

| M 4.WA04 (A) Authentisierung bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| M 4.WA05 (A) Umfassende Ein- und Ausgabevalidierung bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA06 (A) Session-Management bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA07 (A) Fehlerbehandlung durch Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA08 (B) Schutz vor automatisierter Nutzung von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA11 (A) Sichere Konfiguration von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA13 (A) Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA15 (A) Schutz vertraulicher Daten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA16 (A) Zugriffskontrolle bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA19 (B) Verhinderung von Cross-Site Request Forgery (CSRF, XSRF)
| Markus
| in Diskussion
| keiner
|-
| M 4.WA22 (B) Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen
| Markus
| In Diskussion
| keiner
|-
| M 4.WA25 (C) Verhinderung von Clickjacking
| Markus
| in Diskussion
| keiner
|-

| M 4.WA09 (C) Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 56 u. 57 u. 58
|-
| M 4.WA14 (A) Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| Dokument "Webanwendungen_Goldene Regeln.pdf"
| Matthias
| In Diskussion
| keiner
|-
| Dokument "Webanwendungen_Hilfsmittel.pdf"
| unbekannt
| offen
| keiner, 3 Seiten
|-
| Dokument "Webanwendungen_Kreuzreferenztabelle.pdf"
| unbekannt
| offen
| keiner, 2 Seiten
|-
|}
Weitere Informationen und die aktuellen Arbeitsstände gibt es unter [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| "Discussion"]].

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

==Project Contributors==
* Dennis Moers
* Markus Miedaner
* [[User:Mrohr|Matthias Rohr]]
* ''Your name here''

==Project Licence==
Creative Commons Attribution ShareAlike 3.0

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T11:20:34Z

Mrohr: /* M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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) ==

: Verantwortlich fuer Umsetzung
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen
; 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

User:Mrohr

2012-05-21T11:16:57Z

Mrohr:

Matthias Rohr's [profile], [mailto:mail@matthiasrohr.de email address] and and [[:Special:Contributions/Mrohr|wiki contributions]].

=== Experience ===
* 11 years of experience developing Java‐based and PHP-based enterprise web applications
* over 8 years of experience as an application security consultant, engineer, trainer and tester

=== Day Job ===
* Freelance Application Security Consultant
* Main Focus: Software Security Assurance (SSA), SCA and secure software development
* Based in London (UK)

=== OWASP Contributions and Activities ===
* Project Leader of OWASP German Language Project - http://www.owasp.org/index.php/OWASP_German_Language_Project
* Project Leader of OWASP Java Project - http://www.owasp.org/index.php/OWASP_Java_Project
* Project Leader of OWASP Skavenger Project - http://www.owasp.org/index.php/Category:OWASP_Skavenger_Project
* OWASP ASVS German Translation - http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
* ASVS Presentation at OWASP AppSec Germany 2010 - http://www.owasp.org/index.php/OWASP_AppSec_Germany_2010_Conference
* OWASP Summit 2011 - http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference
* OWASP EU Summit 2008 - http://www.owasp.org/index.php/OWASP_EU_Summit_2008
* OWASP Summer of Code 2008 (OWASP Skavenger Project) - http://www.owasp.org/index.php/OWASP_Summer_of_Code_2008
* Co-Author of OWASP paper "Use of Web Application Firewalls" - http://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls

last revised 5/5/2012

User:Mrohr

2012-05-21T11:16:02Z

Mrohr:

Matthias Rohr's [profile], [mailto:mail@matthiasrohr.de email address] and and [[:Special:Contributions/Mrohr|wiki contributions]].

=== Experience ===
* 11 years of experience developing Java‐based and PHP-based enterprise web applications
* over 8 years of experience as security consultant, trainer and tester

=== Day Job ===
* Freelance Application Security Consultant
* Main Focus: Software Security Assurance (SSA), SCA and secure software development
* Based in London (UK)

=== OWASP Contributions and Activities ===
* Project Leader of OWASP German Language Project - http://www.owasp.org/index.php/OWASP_German_Language_Project
* Project Leader of OWASP Java Project - http://www.owasp.org/index.php/OWASP_Java_Project
* Project Leader of OWASP Skavenger Project - http://www.owasp.org/index.php/Category:OWASP_Skavenger_Project
* OWASP ASVS German Translation - http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project
* ASVS Presentation at OWASP AppSec Germany 2010 - http://www.owasp.org/index.php/OWASP_AppSec_Germany_2010_Conference
* OWASP Summit 2011 - http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference
* OWASP EU Summit 2008 - http://www.owasp.org/index.php/OWASP_EU_Summit_2008
* OWASP Summer of Code 2008 (OWASP Skavenger Project) - http://www.owasp.org/index.php/OWASP_Summer_of_Code_2008
* Co-Author of OWASP paper "Use of Web Application Firewalls" - http://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls

last revised 5/5/2012

OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T11:15:07Z

Mrohr: /* Project Contributors */

[[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==
* Time is running out, so it's just: Review!
* Details [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]]


==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==

===Allgemeine Punkte===

[[OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen/Allgemeine_Punkte|Allgemeine Punkte]].

===Kapitel-Review===

Hier eine Auflistung der einzelnen Kapitel / Teile / Review-TODOs - wer einen Teil übernehmen möchte schreibt sich bitte einfach ein (im Feld Person).

Im Kommentarfeld bitte angeben, bis wann ihr plant, den Punkt fertig bearbeitet zu haben (und natürlich sonstige notwendigen Kommentare). Das Kommentarfeld eignet sich auch, um anzugeben, wer den peer review für diesen Teil macht (vgl. Status "in Diskussion").

Unter Status könnt Ihr das folgende angeben:
* offen (dieser Teil ist noch unbearbeitet)
* in Arbeit (dieser Teil wird aktuell bearbeitet)
* in Diskussion (Arbeit des initialen Reviewers abgeschlossen; Kommentierung / peer review durch andere wird durchgeführt)
* geschlossen (die Kommentierung dieses Teils ist abgeschlossen)
* übernommen (dieser Teil wurde in das finale Word-Dokument übernommen)

{| class="wikitable"
|-
! Kapitel / Teil
! Person
! Status
! Kommentar
|-
| B 5.XX Web-Anwendungen, Beschreibung und Abgrenzung (inkl. Seite 5)
| Markus
| in Diskussion
| keiner
|-

| G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-

| G 4.33 Unzureichende oder fehlende Authentisierung
| Matthias
| In Diskussion
| keiner
|-

| G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen
| Tobias
| In Diskussion
| keiner
|-
| G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen
| Matthias
| In Diskussion
| keiner
|-
| G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-

| G 5.131 SQL-Injection
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 17
|-
| G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung
| unbekannt
| offen
| keiner, Seite 18
|-
| G 5.WA10 Fehler in der Logik von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA12 Unzureichendes Session-Management von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 21
|-
| G 5.WA13 Cross-Site Scripting (XSS)
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF)
| Matthias
| in Diskussion
| keiner
|-
| G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 25
|-
| G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 26 u. 27
|-
| G 5.WA17 Injection-Angriffe
| Ralf
| in Arbeit
| keiner
|-
| G 5.WA18 Clickjacking
| unbekannt
| offen
| keiner, Seite 29
|-

| M 2.WA02 (B) Dokumentation der Architektur von Web-Anwendungen
| Matthias
| in Diskussion
| keiner
|-
| M 4.WA20 (A) Sicherer Entwurf der Logik von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 2.WA12 (B) Entwicklung und Erweiterung von Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA21 (A) Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 5.WA23 (A) Systemarchitektur einer Web-Anwendung
| Makrus
| in Diskussion
| keiner
|-
| M 2.WA24 (W) Web-Tracking
| Matthias
| in Diskussion
| keiner
|-

| M 4.WA04 (A) Authentisierung bei Web-Anwendungen
| Matthias
| in Arbeit
| keiner
|-
| M 4.WA05 (A) Umfassende Ein- und Ausgabevalidierung bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA06 (A) Session-Management bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA07 (A) Fehlerbehandlung durch Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA08 (B) Schutz vor automatisierter Nutzung von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA11 (A) Sichere Konfiguration von Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA13 (A) Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA15 (A) Schutz vertraulicher Daten bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA16 (A) Zugriffskontrolle bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| M 4.WA19 (B) Verhinderung von Cross-Site Request Forgery (CSRF, XSRF)
| Markus
| in Diskussion
| keiner
|-
| M 4.WA22 (B) Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen
| Markus
| In Diskussion
| keiner
|-
| M 4.WA25 (C) Verhinderung von Clickjacking
| Markus
| in Diskussion
| keiner
|-

| M 4.WA09 (C) Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen
| unbekannt
| offen
| keiner, Seite 56 u. 57 u. 58
|-
| M 4.WA14 (A) Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen
| Markus
| in Diskussion
| keiner
|-
| Dokument "Webanwendungen_Goldene Regeln.pdf"
| Matthias
| In Diskussion
| keiner
|-
| Dokument "Webanwendungen_Hilfsmittel.pdf"
| unbekannt
| offen
| keiner, 3 Seiten
|-
| Dokument "Webanwendungen_Kreuzreferenztabelle.pdf"
| unbekannt
| offen
| keiner, 2 Seiten
|-
|}
Weitere Informationen und die aktuellen Arbeitsstände gibt es unter [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| "Discussion"]].

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

==Project Contributors==
* Dennis Moers
* Markus Miedaner
* [[User:Mrohr|Matthias Rohr]]
* ''Your name here''

==Project Licence==
Creative Commons Attribution ShareAlike 3.0

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:30:56Z

Mrohr: /* M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:26:11Z

Mrohr: /* M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Haertung von Workflows, etwa durch die Verwendung von State Machines
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch ein weiterer Punkt von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:25:26Z

Mrohr: /* M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Haertung von Workflows, etwa durch die Verwendung von State Machines
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch zwei weitere Punkte von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:25:09Z

Mrohr: /* M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

([[User:Mrohr|Matthias]]) Ehrlich gesagt kann ich nicht ganz nachvollziehen, was der Sichere Entwurf der Logik von Web-Anwendungen mit dem Verzicht auf aktive Inhalte zu tun hat. Unabhaengig davon sollte man solche unsinnigen Aussagen im Jahre 2012 nicht mehr treffen, damit macht man sicht nur laecherlich.

Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)
* Haertung von Workflows, etwa durch die Verwendung von State Machines
* Fail Securely (bzw. Verweis)
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch zwei weitere Punkte von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:14:52Z

Mrohr: /* M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch drei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch zwei weitere Punkte von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T08:14:34Z

Mrohr: /* M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen

; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden

([[User:Mrohr|Matthias]]) Noch zwei Anmerkugnen

; Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"

Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen

; Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen

Der Hinweis waere ggf. erwahnenswert

; Hinweis auf nicht-angemeldeten Bereich

Das Risiko durch rechenintensive Operationen durch einen DoS betroffen zu sein ist natuerlich fuer gewoehlich um so groesser, wenn diese im anonymen Bereich angeboten wird. Der Hinweis ware ggf. ebenfalls hilfreich.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch zwei weitere Punkte von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T07:59:17Z

Mrohr: /* M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen

([[User:Mrohr|Matthias]]) Noch zwei weitere Punkte von mir

; Typische Hintergrundsysteme
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T07:37:49Z

Mrohr: /* M 4.WA25Verhinderung von Clickjacking (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

([[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T07:37:32Z

Mrohr: /* M 4.WA25Verhinderung von Clickjacking (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

[[User:Mrohr|Matthias]] Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T07:37:20Z

Mrohr: /* M 4.WA25Verhinderung von Clickjacking (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

[[User:Mrohr|Matthias]]) Stimmt, auch wenn ich "Angreifer" in dem Beispiel eher als "Webseitenbetreiber" beschreiebn wuerde, da er nicht wirklich aktiv einen Angriff durchfuehrt, oder? Bitte nochmal ueber meinen Hinweis aus G 5.WA18 nachdenken: Ist Clickjacking-Schutz tatsaechlich Grundschutz? Ich bin mir da selber nicht so wirklich sicher.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-21T07:31:55Z

Mrohr: /* G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig ist."

[[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:

; Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."

"Unerreichbarkeit" ist etas merkwuerdig ausgedrueckt, besser ware hier von der "Verfuegbarkeit" zu sprechen. Im Uebrigen fehlt vollstaendig der Bezug auf die Verfuegbarkeit als Primaeres Schutzziel der Informationssicherheit.

; "Clientseitige Fehlerbehandlung"
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)

== 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-18T16:26:50Z

Mrohr: /* M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==
OK - Keine Anmerkungen von mir.

[[User:Mrohr|Matthias]]) Von mir schon;)

; Vermeidung von Kommentaren in ausgelieferten Webseiten

Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.

Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.

; Löschen nicht benötigter Dateien

Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.

Statt Dateien einfach nur zu loeschen (was in der Praxis haeufig nicht so einfach ist) bietet es sich zudem an, den Zugriff auf bestimmte Dateien oder Dateitypen generell zu sperren, etwa mittels ACL im Apache.

; Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}

Persoenlich verstehe ich das nicht. Wieseo neutrale Fehlermeldung? Das macht fuer mich nur beim Login Sin. Hierzu existiert in dem Text auch keinerlei Bezug. Ich wuerde das daher besser entfernen und im Rahmen der Fehlerbehandlung diskutieren. Mindestens sollte hier jedoch besser von "sicherheitsunbedentlichen Fehlermeldungen" oder so gesprochen werden.

; Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?

Diesen Punkt sehe ich als sehr Fallabhengig an. Es kann fuer seiten durchaus wuenschenswert sein, dass der Referer weitergegeben wird. Der Referer sollte natuerlich keine sensiblen Informationen enthalten, was ja an anderer Stelle (etwa Session Management) vorgegeben wird bzw. gegeben werden sollte.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-18T16:11:45Z

Mrohr: /* M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

([[User:Mrohr|Matthias]]) Das sehe ich anders. Brute-Forcing bezieht auf Passwoerter und Enumeration auf Benutzernamen, etwa durchs hochzaehlen. Auch wenn ich zustimmen muss, dass die nicht ganz gluecklich gewaehlt wurden. Stann "Erraten von Zugangsdaten" wuerde ich besser von "Erraten von Passwoertern" sprechen. Oder wie gesagt gleich auch auf andere Beispiele (etwa Object ID Enumeration) beziehen.

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus) ==
OK - Keine Anmerkungen von mir.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-18T13:24:27Z

Mrohr: /* M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) */

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

([[User:Mrohr|Matthias]]) Sorry, meiner Meinung nach hat die Bewertung von Kryptoverfahren hier abslut nichts zu suchen.Stattdessen sollte hier auf den entsprechenden [https://www.bsi.bund.de/ContentBSI/Publikationen/TechnischeRichtlinien/tr02102/index_htm.html Empfehlung des BSI] verwiesen werden, auch wenn dieses Dokument derzeit noch etwas outdated zu sein scheint.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus) ==
OK - Keine Anmerkungen von mir.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.

Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen

2012-05-18T13:19:24Z

Mrohr:

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.

== "Hilfsmittel" (Markus) ==
Ich würde das Script zur Vermeidung von Clickjacking wrappen und nicht als losen Skript-block in den Text einbinden - einfach schlechter Programmierstiel diese losen Blöcke.
Der Zugriff auf das Body-Element mit byTagName-Array[0] ist auch nicht wirklich gut. Ich halte Zugriffe über das DOM (klassisch), bei ID bzw. XPATH für besser.

SQL-Injection Characters:
die Pipe fehlt hier zur Textkonatenierung
+ / - haben auch eine Bedeutung bei JOINs.

== "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.

==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.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias) ==
; Abschnitt "Unsichere Fehlerbehandlung"
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.

; "fehlende SQL-Parameter,"
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.

; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"
Korrekt, allerdings nicht nachvollziehbar, wenn das Problem der Leser nicht schon bekannt ist. Daher erweitern nach " Rahmen von Brute-Force-Angriffen ausgenutzt werden." mit ". Bei Brute-Force-Angriffen wäre in diesem Fall klar, dass der Benutzername gültig 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.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.
"(z. B. durch Kommentare im
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener
Lösungen sowie zu Dokumentationszwecken sollte die Historie der
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.
;Generell geht der Autor leider nicht auf die Rollen & Rechte Verteilung ein. Mir fehlt der Hinweis, das es eine personelle Trennung zwischen Entwicklung, Test und Betrieb geben muss.
;Zum Thema Wartung / Betrieb --> Hier wird keine Aussage getroffen bezüglich Log_Files. Dieses Thema kann kritische Auswirkungen haben, Bsp.: logging ganzer HTTP-Requests im LogLevel=Debug.
; "Produktspezifische Sicherheitsfunkionalität" - Dieser Absatz ist gefährlich - der Angreifer ist nicht zur Verwendung dies Zielbrowsers gezwungen. Deshalb können Browser-spez. Sicherheitsfunktionen nur als Add-ON gewertet werden.
; "Festlegung der Entwicklungsumgebung" - Dieser Absatz geht nicht auf die zu verwendenden Testdaten ein. Der Hinweis, dass Live-Daten / Kundendaten nichts in Test- & Entwicklungsumgebungen zu suchen haben fehlt!!!

== 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.

== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==
; "Ablehnung der Daten im
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.

== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==
; "Übertragung der SessionID mittels GETRequest" --> Hier fehlt der Hinweis, dass die Lebensdauer dieser SessionIds kurz/kürzer sein muss, als im Falle der Speicherung im Cookie.

([[User:Mrohr|Matthias]]) Die Anmerkung verstehe ich ehrlich gesagt ueberhaupt nicht, zumal das SM haeufig transparent zwischen Cookies und URL Rewriting wechselt. Wozu soll das gut sein? Wie soll das geschehen? Idealerweise sollte die Session ID niemals in die URL geschrieben werden, das sollte eigentlich genuegen.

; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!

([[User:Mrohr|Matthias]]) Solange hier nicht auf eine explizite TLS Version eingegangen wird, sollte meiner grossen Ueberzeugung nach hier auch auf keine Exploits etc. eingagen werden, das gehoert an andere Stelle.

; ([[User:Mrohr|Matthias]]) Weiterhin:

Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.

Die Aussage finde ich etwas problematisch, wichtiger ist, dass die Entropie ausreichend hoch ist. Haeufig werden etwa IPs von Load Balancern in die Session ID hineingeschrieben.

- Domain (z. B. webapp.domain.tld),
- Path (z. B. /webapp/),
- Secure und
- HttpOnly.Beschränkte Sitzungsdauer

Das sieht so aus, als ob es empfehlenswert ist, das Domain-Tag zu verwenden, das ist es sicherlich nicht. Was macht hier der Hinweis "Beschraenke Sizuungsdauer"?

== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus) ==
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.

== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus) ==
; "Brute-Force-
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration

== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus) ==
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.

== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==
; Datei-Upload: Bei einem Upload werden Dateien durchaus in TEMP-Verzeichnissen gesammelt und danach weiterverarbeitet. Diese TEMP-Verzeichnisse sind im Rahmen einer Sicherheitsanalyse zu betrachten -> Möglicher (unbefugter) Zugriff auf weitere Uploads
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.

== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus) ==
OK - Keine Anmerkungen von mir.

== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus) ==
; Sichere kryptographische Algorithmen:
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.
; Schlüssel
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?
; Schutz der Daten im Browsercache
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.
; Maskierung von Passwörtern
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.
; Sicherung von Zugangsdaten:
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.
; Schutz von Quelltexten:
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?
Bei include-befehlen sind die pfadangaben zu überdenken.

== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==
; Zugriffskontrolle via Frameworks:
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.
; Datei Upload:
Die Gefahr eines DOS wird hier nicht erwähnt.

== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==
; Verantwortliche:
Entwickler und Admins!
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge

; Anti-CSRF-Token in hidden fields:
Das ist keine gute Idee. Ich würde das streichen!

([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!!

([[User:Mrohr|Matthias]]) Die Technik bei der die Session ID als Anti-CSRF-Token verwendet wird, wird als Double-Cookie Submit bezeichnet, das sollte hier referenziert werden.

; Umgehung von Schutzmechanismen:
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.

; Frameworks:
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?

([[User:Mrohr|Matthias]]) Sehe ich persoenlich nicht so, da CSRF primaer ein Applikations-Fehler ist, und auch in der Applikation und nicht im Environment (AppServer) geloest werden sollte. Auch wenn das manchmal ggf. die einzig machbare Loesung darstellt.

([[User:Mrohr|Matthias]]) Was generell fehlt, ist ein Hinweis darauf, dass schreibende Requests generell per HTTP Post abgewickelt werden sollten, da HTTP Get keine "Safe Method" (siehe HTTP 1.1, RFC 2616) ist.

== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus) ==
; Rollbacks:
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.
; RaceConditions:
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.

== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus) ==
; Datenspeicher:
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.
; Voraggregation von Daten / Caching
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.

== M 4.WA25Verhinderung von Clickjacking (Markus) ==
Ok - das passt soweit.

== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus) ==
; Verantwortliche:
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.
; DirectorySystem Beispiel:
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.
; Firewalls:
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?

== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus) ==
; Verantwortliche:
Auch hier fehlend wieder die Architekten.
; Virtualisierung:
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.