Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen - Revision history

Ralf Reinhardt: Typo

2012-06-11T15:49:36Z

Typo

Ralf Reinhardt: /* G 5.WA13 Cross-Site Scripting (XSS) (Ralf) */

2012-06-11T14:46:45Z

‎G 5.WA13 Cross-Site Scripting (XSS) (Ralf)

Ralf Reinhardt: /* G 5.WA13 Cross-Site Scripting (XSS) (Ralf) */

2012-06-11T14:45:29Z

‎G 5.WA13 Cross-Site Scripting (XSS) (Ralf)

Kai Jendrian: /* G 5.WA13 Cross-Site Scripting (XSS) (Ralf) */

2012-06-06T09:23:29Z

‎G 5.WA13 Cross-Site Scripting (XSS) (Ralf)

Kai Jendrian: /* M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) */

2012-06-06T08:48:45Z

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

Kai Jendrian: /* M 2.WA24 Web-Tracking (Matthias) */

2012-06-06T08:45:24Z

‎M 2.WA24 Web-Tracking (Matthias)

Kai Jendrian at 06:48, 6 June 2012

2012-06-06T06:48:45Z

Kai Jendrian at 14:56, 5 June 2012

2012-06-05T14:56:25Z

Show changes

Kai Jendrian at 13:56, 5 June 2012

2012-06-05T13:56:21Z

Ralf Reinhardt at 09:33, 5 June 2012

2012-06-05T09:33:37Z

@@ Line 38: / Line 38: @@
 "JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.
-Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS".
+Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "reflexives XSS".
 Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden,
@@ Line 45: / Line 45: @@
 === Verbindlichkeit ===
 Im Baustein wird fast durchgängig ''sollte'' für Maßnahmen verwendet. Im Sinne der Prüfbarkeit im Rahmen von Zertifizierungsaudits ist in dem Baustein schärfer zwischen Maßnahmen mit empfehlendem und verbindlichem Charakter auch sprachlich zu unterscheiden.
 == "Hilfsmittel" (Markus, Matthias) ==

@@ Line 430: / Line 430: @@
 ;Nachtrag zum Wikipedia-Artikel:
-Der im Entwurf des Bausteins zum Thema XSS zu findente Content wurde von http://de.wikipedia.org/wiki/Cross-Site-Scripting übernommen, inklusive der darin enthaltenen Fehler. <b>In aller Deutlichkeit: Es heißt "reflektiertes XSS" und eben *nicht* <s>reflexives XSS</s></b>, das ist falsch und wird immer wieder falsch zitiert / kopiert / geklaut. Der "Redakteur", der den Wikipedia-Artikel "verwaltet", sieht das noch nicht ein, daher gibt es aktuelle eine Diskussion: http://de.wikipedia.org/wiki/Diskussion:Cross-Site-Scripting#Reflektiertes_XSS . Ich hoffe, der Artikel entspricht bald den Tatsachen, sobald bei den Wiki<s>wichtigwichten</s>-Leuten der Erkenntnisprozess einsetzt.
+Der im Entwurf des Bausteins zum Thema XSS zu findente Content wurde von http://de.wikipedia.org/wiki/Cross-Site-Scripting übernommen, inklusive der darin enthaltenen Fehler. <b>In aller Deutlichkeit: Es heißt "reflektiertes XSS" und eben *nicht* <s>reflexives XSS</s></b>, das ist falsch und wird immer wieder falsch zitiert / kopiert / geklaut. Der "Redakteur", der den Wikipedia-Artikel "verwaltet", sieht das noch nicht ein, daher gibt es aktuelle eine Diskussion: http://de.wikipedia.org/wiki/Diskussion:Cross-Site-Scripting#Reflektiertes_XSS . Ich hoffe, der Artikel entspricht bald den Tatsachen, sobald bei den Wiki<!--wichtigwichten-->-Leuten der Erkenntnisprozess einsetzt.
 == G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==

@@ Line 413: / Line 413: @@
 ([[User:Kai Jendrian|Kai]]) Bei der Übersetzung der Top 10 haben wir darüber diskutiert und uns bewusst für "reflektiert" entschieden. "reflexiv" bedeutet '''sich (auf das Subjekt) zurückbeziehend; rückbezüglich''' was dem Problem von '''reflected XSS''' nicht gerecht wird.
 Mir scheint die einzige Quelle für '''reflexives XSS''' die deutsche Wikipedia zu sein - die in meinen Augen an dieser Stelle schlicht falsch übersetzt.
 ; Erstes Beispiel, persistentes XSS, Mitte:
@@ Line 418: / Line 428: @@
 Ist nicht vollständig korrekt. Es muss heißen:
 "[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."
 == G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==

@@ Line 410: / Line 410: @@
 Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.
 In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)
 ; Erstes Beispiel, persistentes XSS, Mitte:

← Older revision		Revision as of 08:48, 6 June 2012
Line 563:		Line 563:

	([[User:Kai Jendrian\|Kai]]) Der Verweis auf 2-Faktor-Authentifzierung kommt mir hier zu kurz. Gerade SSL/TLS bietet mit Client-Zertifikaten einen hilfreichen Sicherheitsmechanismus.		([[User:Kai Jendrian\|Kai]]) Der Verweis auf 2-Faktor-Authentifzierung kommt mir hier zu kurz. Gerade SSL/TLS bietet mit Client-Zertifikaten einen hilfreichen Sicherheitsmechanismus.
		+
		+	([[User:Kai Jendrian\|Kai]]) Mir fehlt hier auch bei der Behandlung von Passwörtern, dass diese nicht direkt oder symmetrisch verschlüsselt gespeichert werden sollen. Es ist auch bei der Behandlung vergessener Passwörter darauf zu verzichten, diese im Klartext an den Benutzer zu schicken.

	== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==		== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==

← Older revision		Revision as of 08:45, 6 June 2012
Line 513:		Line 513:

	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.		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.
		+
		+	([[User:Kai Jendrian\|Kai]]) Handelt es sich hierbei um eine Maßnahme, die für IT-Grundschutz relevant ist? Das ist doch eher eine Datenschutz als eine Sicherheitsmaßnahme.

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

@@ Line 672: / Line 672: @@
 ; 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.

@@ Line 25: / Line 25: @@
 * Die Maßnahmen sollen verständlich und anwendbar sein.
-== Rechtschreibung (Dirk, Ralf) ==
+== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==
 ''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken.
-Das könnte man machen, wenn man der Meinung ist, dass ''Web'' immer noch ein Fremdwort und kein Lehnwort (=in der deutschen Sprache angekommen) ist.
+Das könnte man machen, wenn man der Meinung ist, dass ''Web'' immer noch ein Fremdwort und kein Lehnwort (=in der deutschen Sprache angekommen) ist. Auf Basis der Interpretation des Duden wurde für die Übersetzung der OWASP Top 10 die einheitliche Schreibweise ''Webanwendung'' verwendet.
 Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.
@@ Line 40: / Line 40: @@
 Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS".
 Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden,
 == "Hilfsmittel" (Markus, Matthias) ==
@@ Line 53: / Line 57: @@
 ([[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) ==
+([[User:Kai Jendrian|Kai]]) Die Priorisierung der Hilfsmittel finde ich nicht passend. Ich würde mir an dieser Stelle eher Verweise auf hilfreiche Werkzeuge und auch geprüfte Bibliotheken erwarten (z. B. ESAPI).
 Hier meine Anmerkungen zu diesem Dokument:
-; 1. Für mich fehlende Punkte
+; 1. Fehlende Punkte:
-* Korrektur der Ursache (Root Cause) von Schwachstellen statt  Verhinderung deren Ausnutzung
+* 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
+* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen
-* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklerative vor programmatischer Sicherheit.
+* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.
 ; 2. Begriff "Web-Anwendung"
-Würde ich generell durch "Webanwendung" ersetzen.
+Würde ich generell durch "Webanwendung" ersetzen (s.o.).
 ; 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....."
@@ Line 78: / Line 86: @@
 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...."
@@ Line 88: / Line 98: @@
 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. ...."
@@ Line 96: / Line 108: @@
 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."
@@ Line 103: / Line 117: @@
 ; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"
-Hier würde ich eher schreiben "(IN Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"
+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."
@@ Line 114: / Line 128: @@
 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."

@@ Line 25: / Line 25: @@
 * Die Maßnahmen sollen verständlich und anwendbar sein.
 == "Hilfsmittel" (Markus, Matthias) ==
@@ Line 396: / Line 411: @@
 == G 5.WA17 Injection-Angriffe  (Ralf) ==
 ; Grundsätzliches Vorgehen
-ersetze "Interpreter mit "Parser oder Interpreter"
+ersetze "Interpreter" mit "Parser oder Interpreter"
 == G 5.WA18 Clickjacking (Matthias) ==