https://wiki.owasp.org/api.php?action=feedcontributions&feedformat=atom&user=Kai+JendrianOWASP - User contributions [en]2026-05-31T13:26:24ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=178692OWASP Stammtisch Karlsruhe2014-07-14T09:12:06Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab August 2014 haben wir die Zeit für den OWASP Stammtisch am ersten Monatg im Monat auf '''19:00 Uhr''' vorverlegt!<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 12. OWASP Stammtisch Karlsruhe am 04.08.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 04.08. um '''19:00h''' in den Räumlichkeiten von [http://www.secorvo.de/unternehmen/anfahrt/anfahrt.php Secorvo] [http://osm.org/go/0DPu1v2gB--?layers=Q&m=&way=257966761 (Ettlinger Str. 12-14, 76137 Karlsruhe)] statt. Für die Planung, meldet Euch bitte unter http://doodle.com/pmvqsffiw7uk2na4 an. Nach einem Vortrag werden wir dann in eine Kneipe in der Nähe wechseln.<br />
<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=178691OWASP Stammtisch Karlsruhe2014-07-14T09:11:38Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab August 2014 haben wir die Zeit für den OWASP Stammtisch am ersten Monatg im Monat auf '''19:00 Uhr''' vorverlegt!<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 12. OWASP Stammtisch Karlsruhe am 04.08.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um '''19:00h''' in den Räumlichkeiten von [http://www.secorvo.de/unternehmen/anfahrt/anfahrt.php Secorvo] [http://osm.org/go/0DPu1v2gB--?layers=Q&m=&way=257966761 (Ettlinger Str. 12-14, 76137 Karlsruhe)] statt. Für die Planung, meldet Euch bitte unter http://doodle.com/pmvqsffiw7uk2na4 an. Nach einem Vortrag werden wir dann in eine Kneipe in der Nähe wechseln.<br />
<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=178690OWASP Stammtisch Karlsruhe2014-07-14T09:11:11Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab August 2014 haben wir die Zeit für den OWASP Stammtisch am ersten Monatg im Monat auf '''19:00 Uhr''' vorverlegt!<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 12. OWASP Stammtisch Karlsruhe am 04.08.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um '''19:00h''' in den Räumlichkeiten von [http://www.secorvo.de/unternehmen/anfahrt/anfahrt.php Secorvo] [http://osm.org/go/0DPu1v2gB--?layers=Q&m=&way=257966761 (Ettlinger Str. 12-14, 76137 Karlsruhe) statt. Für die Planung, meldet Euch bitte unter http://doodle.com/pmvqsffiw7uk2na4 an. Nach einem Vortrag werden wir dann in eine Kneipe in der Nähe wechseln.<br />
<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=178689OWASP Stammtisch Karlsruhe2014-07-14T09:10:36Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab August 2014 haben wir die Zeit für den OWASP Stammtisch am ersten Monatg im Monat auf '''19:00 Uhr''' vorverlegt!<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 12. OWASP Stammtisch Karlsruhe am 04.08.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um '''19:00h''' in den Räumlichkeiten von [http://www.secorvo.de/unternehmen/anfahrt/anfahrt.php Secorvo] [http://osm.org/go/0DPu1v2gB--?layers=Q&m=&way=257966761 (Ettlinger Str. 12-14, 76137 Karlsruhe) statt. Für die Planung, meldet Euch bitte unter [http://doodle.com/pmvqsffiw7uk2na4] an. Nach einem Vortrag werden wir dann in eine Kneipe in der Nähe wechseln.<br />
<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=178688OWASP Stammtisch Karlsruhe2014-07-14T09:10:07Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab August 2014 haben wir die Zeit für den OWASP Stammtisch am ersten Monatg im Monat auf '''19:00 Uhr'' vorverlegt!<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 12. OWASP Stammtisch Karlsruhe am 04.08.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um '''19:00h''' in den Räumlichkeiten von [http://www.secorvo.de/unternehmen/anfahrt/anfahrt.php Secorvo] [http://osm.org/go/0DPu1v2gB--?layers=Q&m=&way=257966761 (Ettlinger Str. 12-14, 76137 Karlsruhe) statt. Für die Planung, meldet Euch bitte unter [http://doodle.com/pmvqsffiw7uk2na4] an. Nach einem Vortrag werden wir dann in eine Kneipe in der Nähe wechseln.<br />
<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=176715OWASP Stammtisch Karlsruhe2014-06-10T07:50:49Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy Doodle-Umfrage 11. Stammtisch OWASP Karlsruhe]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=176714OWASP Stammtisch Karlsruhe2014-06-10T07:50:12Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 11. OWASP Stammtisch Karlsruhe am 07.07.2014 =====<br />
<br />
Der nächste OWASP-Stammtisch in Karlsruhe findet am 07.07. um 20h statt.<br />
Es gibt vorher - hoffentlich :) - einen Vortrag und danach lassen wir<br />
den Abend in einer Kneipe ausklingen. Die Räumlichkeiten stellt dieses<br />
Mal die [https://goo.gl/maps/g6qkU 1&1 Internet AG in der Ernst-Frey-Strasse 10].<br />
<br />
Da wir Wachpersonal vor Ort haben und Besucherausweise ausstellen müssen,<br />
brauchen wir bis zum 03.07. eine möglichst genaue Teilnehmerliste. Ist auch<br />
ganz praktisch zum "Tisch danach" bestellen. Tragt euch bitte in das<br />
folgende Doodle ein. Nachzügler können wir auch vor Ort verarzten :)<br />
<br />
[http://doodle.com/phd2wqh8epevcccy]<br />
<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=174572OWASP Stammtisch Karlsruhe2014-05-09T09:22:44Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Der 10. Karlsruher OWASP Stammtisch findet am '''02.06.2014''' um '''20:00 Uhr''' bei [https://goo.gl/maps/Vh1CN SAP Research], Vincenz-Prießnitz-Straße 1, 76131 Karlsruhe statt. Wir werden mit einem Vortrag und einer thematischen Diskussion starten (Thema wird noch bekannt gegeben) und danach dann zum gemütlichen Teil in eine nahegelegene Kneipe wechseln. Da der Raum bei SAP zutrittsbeschränkt ist, werden wir am Eingang Informationen aushängen wie man den Stammtisch findet. Es wäre aber schön, wenn sich möglichst viele um 20:00 Uhr dort einfinden könnten und wir gemeinsam reingehen könnten.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=174337OWASP Stammtisch Karlsruhe2014-05-06T08:00:44Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Vortragsthema und Ort werden noch per E-Mail und Twitter bekannt gegeben.<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=174336OWASP Stammtisch Karlsruhe2014-05-06T08:00:28Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
'''ACHTUNG:''' Ab Juni 2014 findet der OWASP Stammtisch Karlsruhe immer am '''ersten Montag im Monat um 20:00 Uhr''' statt. Wir wollen mit einem Vortrag bei einem Unternehmen starten und danach zum gemütlichen Teil übergehen. Vortragsthema und Ort werden ca. 2 Wochen vor dem Stammtisch bekannt gegeben.<br />
<br />
===== 10. OWASP Stammtisch Karlsruhe am 02.06.2014 =====<br />
<br />
Vortragsthema und Ort werden noch per E-Mail und Twitter bekannt gegeben.<br />
<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=174061OWASP Stammtisch Karlsruhe2014-05-02T06:29:05Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
===== 9. Pizza-Essen für die Sicherheit am 05.05.2014 =====<br />
<br />
Der 9. Karlsruher OWASP Stammtisch findet am '''05.05.2014''' um '''20:00 Uhr''' in der [http://pizzeria-la-famiglia.de/ Pizzeria La Famiglia], Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort.<br><br />
Im Vordergrund des Stammtisches steht die Vorbereitung des [http://www.entwicklertag.de/karlsruhe/2014/ Entwicklertags Karlsruhe 2014]. Ansonsten haben wir wohl endlich wieder eine Tafel, so dass wir wieder unsere '''Board and Chalk Talks''' starten können - immer her mit spannenden Themen!<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=161174OWASP Stammtisch Karlsruhe2013-10-21T08:07:02Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der [http://goo.gl/maps/DtQsP Leopoldstraße 3] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=161173OWASP Stammtisch Karlsruhe2013-10-21T08:05:30Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
===== 8. Pizza-Essen für die Sicherheit am 24.10.2013 =====<br />
<br />
Am '''24.10.2013''' wollen wir uns um '''20:00 Uhr''' im Restaurant [http://www.lincontro.de l'incontro] in der Karlsruher Innenstadt treffen. Thematisch soll ein Schwerpunkt die Beteiligung des Karlsruher OWASP Stammtisches am [http://www.entwicklertag.de Entwicklertag 2014] sein.<br />
<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany&diff=157488Germany2013-08-29T10:00:29Z<p>Kai Jendrian: </p>
<hr />
<div>__NOTOC__<br />
<br />
<!-- Top News:it-sa, am 08.10.13 wieder entfernen --><br />
<div>'''Find us at it-sa fair 2013 at 12.107'''<br />
[[Image:owasp-it-sa-2013.gif]]<!-- am 08.10.13 wieder entfernen --><br />
</div><br />
<br />
{{Chapter Template|chaptername=Germany<br />
|extra=[[Image:owasp_germany_logo.png|right]]<br />
<br />
The chapter leader is [mailto:tobias.glemser@owasp.org Tobias Glemser].<br />
<br />
Chapter Board members are: [mailto:achim@owasp.org Achim Hoffmann], [mailto:emin.tatli@owasp.org Emin Tatlı], Martin Johns, [mailto:dirk@owasp.org Dirk Wetter], [mailto:kai@owasp.org Kai Jendrian].<br />
<br />
<span style="color: white; text-decoration:"><br />
|emailarchives=https://lists.owasp.org/pipermail/owasp-germany<br />
</span><br />
}}<br />
<br />
==== OWASP German Chapter Sponsorships ====<br />
<br />
<!-- Sponsoren: bitte 3-spaltige Tabelle benutzen, damit genuegend Abstand zwischen den Bildern --><br />
{| width="99%" style="background-color:inherit;"<br />
| [[Image:Schutzwerk-300x29.png|link=http://www.schutzwerk.com|www.schutzwerk.com]]<br />
| [[Image:TC-Logo-mit-Firmennamen-RGB.png|link=http://www.tele-consulting.com|www.tele-consulting.com]]<br />
|-<br />
| [[Image:sicsec_logo_was_OWASP_20121218_small.png|link=http://www.sicsec.de|www.sicsec.de]]<br />
| [[Image:Cyberday-logo_8700px_square.png|link=https://www.cyberday-gmbh.de|www.cyberday-gmbh.de]]<br />
|-<br />
|<br />
|<br />
|<br />
|}<br />
<br />
Unser Angebot an Sponsoren / Offer for Chapter Sponsors: <u>[[Germany/Chaptersponsor|OWASP German Chapter Sponsorship]]</u>.<br />
<br />
<br />
== '''OWASP German Chapter''' ==<br />
<br />
[[File:Logo AppSecEU2013-Nr3backg50.png|798px|center|link=https://owasp.org/index.php/AppSecEU2013|(original photo from IqRS)]]<br />
<!-- Top News: auf hellblauem Hintergrund ganz oben auf der Seite --><br />
<div style="background-color:rgb(153,204,255);margin:2em;padding-left:1em;"><big style="padding:1em;"><br />
Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
<br />
The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
<br />
</big></div><br />
<br />
----<br />
;Mitstreiter: Wir suchen engagierte Personen, die das German Chapter als Ansprechpartner für Firmen und Branchen vertreten. Weitere Details folgen in Kürze hier.<br />
----<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Aktuelles ===<br />
---- <br />
;10.08.2013: Partnerschaft mit dem [http://www.isaca.de/ ISACA Germany Chapter e.V.]: Zum Nutzen für Mitgleider beider Seiten wurde mit dem ISACA Germany Chapter e.V. eine Partnerschaft geschlossen. Die Partnerschaft ermöglicht es Mitgliedern des ISACA Germany Chapter e.V. an der OWASP AppSec Research 2013 zu vergünsigten Konditionen teilzunehmen. Das OWASP German Chapter erhält Gelegenheit auf ISACA Konferenzen präsent zu sein. Wir freuen uns sehr auf die Partnerschaft.<br />
;01.07.2013: Programm für AppSec Research EU 2013 ist [http://owaspappseceu2013.sched.org/ online] <!-- http://sched.appsec.eu/ ist Tracking-Seite, grrrr --><br />
;10.06.2013: Regestrierung für AppSec Research EU 2013 ist hier [https://appsec.eu/registration/ https://appsec.eu/registration/] .<br />
;17.05.2013: OWASP Germany Chapter Meeting in Frankfurt; Details und Agenda sind <u>[[Germany/Chapter_Meetings|hier]]</u> zu finden.<br />
;22.02.2013: German Chapter Meeting findet am '''17.05.2013''' in Frankfurt statt.<br />
;5.12.2012: Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
: The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
;10.11.2012: <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]:</u> Die hochrangige Websicherheitskonferenz war ein voller Erfolg: Dank gilt allen Besuchern -- gut ein Drittel mehr als letztes Jahr -- Sprechern und Sponsoren.<br />
;07.11.2012: <u>[[Germany/Chaptersponsor|Chapter Sponsorsing]]</u> möglich.<br />
;03.11.2012: Webseite des [[Germany|OWASP German Chapter]] neu strukturiert.<br />
;10.09.2012: <u>[[German_OWASP_Day_2012/Programm|Programm]]</u> für <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u> in München am 7.11.2012 steht<br />
;13.07.2012: Am Ende der AppSecEU 2012 wurde offiziell verkündet, dass das Deutsche Chapter die AppSecEU Research 2013 hostet. Ort Hamburg, Zeit: Juli <br />
;02.05.2012: Call for Presentations offen für <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u>. Ort: München, Zeit: 7.11.2012<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== News ===<br />
----<br />
(see left side)<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
Ältere Nachrichten sind <u>[[Germany/Aktuelles|hier]]</u> archiviert.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
Old news (what a nice name :-) can be found <u>[[Germany/Aktuelles|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Unsere Konferenzen ===<br />
----<br />
;20. - 23.08.2013: Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
;7.11.2012: <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u> in München<br />
<br />
Eine Liste aller vom OWASP German Chapter durchgeführten Konferenzen ist <u>[[Germany/Konferenzen|hier]]</u> zu finden.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== German Conferences ===<br />
----<br />
;20. - 23.08.2013: The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
<br />
<br />
A list of conferences organized by the OWASP German Chapter can be found <u>[[Germany/Konferenzen|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Projekte des German Chapter ===<br />
----<br />
Das German Chapter initiiert oder beteiligt sich an <u>[https://www.owasp.org/index.php/Category:OWASP_Project OWASP Projekten]</u>. Die Liste der <u>[[Germany/Projekte|deutschen Projekte ist hier]]</u> zu finden.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Projects of German Chapter ===<br />
----<br />
The German Chapter initiated or participated at [https://www.owasp.org/index.php/Category:OWASP_Project OWASP Projects]. A List can be found <u>[[Germany/Projekte|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== OWASP Stammtisch-Initiative ===<br />
----<br />
<br />
In mehren Städten gibt es <u>[[Germany/Stammtisch_Initiative|OWASP-Stammtisch]]</u>, bei denen man sich in lockerer Runde im Biergarten oder Gasthaus trifft um sich auszutauschen, nette Leute kennenzulernen oder auch ernsthafte Sicherheitsthemen zu diskutieren. <br />
<br />
Aktive Stammtische gibt es (Stand 2011) in:<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |München]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Köln]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== OWASP Regular Tables ===<br />
----<br />
A "regular's table" (Stammtisch) is a German tradition for meeting each other in a beer garden or a pub in order to discuss certain topics (and to drink beer, of course&nbsp;;-).<br />
<br />
In the case of an <u>[[Germany/Stammtisch_Initiative|OWASP-Stammtisch]]</u> it's all about Web Application Security. Right now a Stammtisch is established in <br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |Munich]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Cologne]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Chapter Meetings ===<br />
----<br />
<br />
Das German Chapter trifft sich in unregelmäßigen Abständen, um die Arbeit innerhalb des German Chapter zu organisieren.<br />
Gemäß dem ''O'' in OWASP für ''open'' sind diese Treffen öffentlich. Jedermann kann daran teilnehmen und sich ander Arbeit im Chpater beteiligen. Der Termin zum Treffen -- Chapter Meeting -- wird auf dieser Seite bekannt gegegebn, zusammen mit der Agenda. Selbstverständlich sind auch alle Ergebnisse der Treffen öffentlich. Was auf den vergangenen Treffen jeweils besprochen und beschlossen wurde ist auf der <u>[[Germany/Chapter_Meetings|Chapter Meetings]]</u>-Seite zu finden.<br />
<br />
Leztes Chapter Meeting war am '''17.05.2013''' in Frankfurt. Details sind auf der <u>[[Germany/Chapter_Meetings|Chapter Meetings]]</u>-Seite zu finden<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Chapter Meetings ===<br />
----<br />
The German Chapter meetings are anounced here. All oucomes of previous meetings will be found on <br />
<u>[[Germany/Chapter_Meetings|Chapter Meetings]]</u>.<br />
<br />
'''Note''' that this page is in German mainly.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== So erreichen Sie uns ===<br />
----<br />
;Twitter: [https://twitter.com/#!/search/OWASP_de Twitter: @OWASP_de] <br />
;Mailing-Liste: <u>[https://lists.owasp.org/mailman/listinfo/owasp-germany owasp-germany@lists.owasp.org]</u> <u>[https://lists.owasp.org/pipermail/owasp-germany Mailarchiv]</u><br />
<br />
Jede Mitarbeit am OWASP German Chapter ist willkommen. Wir freuen uns auf Beiträge in unserer <u>[https://lists.owasp.org/mailman/listinfo/owasp-germany Mailingliste]</u>. Diese sollten natürlich einen Bezug zu (Web-)Anwendungssicherheit haben. Denkbar sind also u. A. Fragen, Tipps, aktuelle Hinweise, Stellenangebote oder Projektgesuche. Es gibt auch ein <u>[https://lists.owasp.org/pipermail/owasp-germany Mailarchiv]</u> von der Liste. Wenn Sie nicht an den Meetings teilnehmen können, kontaktieren Sie einfach einen der German Chapter Board Members (siehe oben) oder schreiben Sie eine E-Mmail an uns [mailto:owasp-germany@lists.owasp.org chapter mailing list].<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
=== Contact us ===<br />
----<br />
If you want to participate in the work of the OWASP German Chapter or offer to submit work to it and cannot attend the meeting, please contact any of the German Chapter Board members (see above) or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list]. <br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Presse ===<br />
----<br />
Informationen für die Presse finden sich <u>[[Germany/press|hier]]</u><br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
=== Press Relations ===<br />
----<br />
Press Relations of the OWASP German Chapter are currently directed exclusively towards the local press. We therefore do not provide english translations.<br />
<br />
* <u>[[Germany/press|Press relations]]</u><br />
|}<br />
<br />
<small>(Kleines [[Germany/Website_HowTo| HowTo]] für die deutschen wiki-Seiten)</small><br />
<br />
[[Category:Germany]] [[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=156193User:Kai Jendrian2013-07-29T12:02:13Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 17 years of Network and Application operations and security<br />
* over 8 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee<br />
* Translation OWASP Top 10 German<br />
<br />
=== Social Network ===<br />
<br />
* [https://twitter.com/OWASP_KA @OWASP_KA]<br />
* [https://twitter.com/_ccurity @_ccurity]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=156192OWASP Stammtisch Karlsruhe2013-07-29T12:00:50Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
Neuigkeiten zu OWASP Karlsruhe auf Twitter unter [https://twitter.com/OWASP_KA @OWASP_KA].<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=155204OWASP Stammtisch Karlsruhe2013-07-07T10:25:01Z<p>Kai Jendrian: /* Karlsruhe */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Treffpunkt ist um 20:00 Uhr die Vereinsgaststätte des TC Neureut, Rechts der langen Richtstatt 6, 76149 Karlsruhe Neureut (http://goo.gl/maps/rI3bR). Mit der Straßenbahn fahrt Ihr mit der S1 oder S11 bis zur Haltestelle Welschneureuter Straße und seit dann zur Fuß in ca. 5-10 Minuten vor Ort. Das Lokal befindet sich nur ca. 100 m entfernt vom Treffpunkt des letzten Stammtisches.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=154357OWASP Stammtisch Karlsruhe2013-06-24T11:05:06Z<p>Kai Jendrian: /* 7. Zusammenhocken für die Sicherheit am ??.??.2013 */</p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am 11.07.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wir treffen uns am '''11.07.2013''' um '''20:00 Uhr'''. Ein Ort steht leider noch nicht fest, da wir leider immer noch keine geniale Lokation in Karlsruhe gefunden haben. Ich nehme gerne Vorschläge per [mailto:kai.jendrian@owasp.org E-Mail] entgegen.<br />
Eine E-Mail mit einem Ort wird Anfang Juli folgen.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=154113OWASP Stammtisch Karlsruhe2013-06-19T11:17:42Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
===== 7. Zusammenhocken für die Sicherheit am ??.??.2013 =====<br />
<br />
Große Ereignisse werfen ihre Schatten voraus. Nach diesem Motto wollen wir uns noch einmal vor der [https://appsec.eu AppSec Research 2013] in Karlsruhe treffen und über die Sicherheit von Anwendungen in einem gemütlichen Rahmen austauschen. Wie gewohnt, stehen verschiedene mögliche Termine zur Auswahl. Bitte tragt Euch bis zum 27.06.2013 in die [http://www.doodle.com/rhv9vvb394yikz6u Doodle-Umfrage für den Stammtisch] ein. Ein Ort steht auch noch nicht fest, da wir leider immer noch keine geniale Lokation in Karlsruhe gefunden haben. Ich nehme gerne Vorschläge per [mailto:kai.jendrian@owasp.org E-Mail] entgegen.<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany&diff=152062Germany2013-05-22T16:28:41Z<p>Kai Jendrian: </p>
<hr />
<div>__NOTOC__<br />
<br />
<br />
<!-- Top News: Chapter Meeting, am 18.5.13 wieder entfernen --><br />
<div style="background-color:rgb(153,204,255);margin:2em;padding-left:1em;"><big style="padding:1em;"><br />
Das '''OWASP Germany Chapter Meeting''' fand am 17.05.2013 in Frankfurt statt;<br />
Details und Agenda sind <u>[[Germany/Chapter_Meetings|hier]]</u> zu finden.<br />
</big></div><!-- am 18.5.13 wieder entfernen --><br />
<br />
<br />
{{Chapter Template|chaptername=Germany<br />
|extra=[[Image:owasp_germany_logo.png|right]]<br />
<br />
The chapter leader is [mailto:tobias.glemser@owasp.org Tobias Glemser].<br />
<br />
Chapter Board members are: [mailto:achim@owasp.org Achim Hoffmann], [mailto:emin.tatli@owasp.org Emin Tatlı], Martin Johns, [mailto:dirk.wetter@owasp.org Dirk Wetter], [mailto:kai.jendrian@owasp.org Kai Jendrian].<br />
<br />
<span style="color: white; text-decoration:"><br />
|emailarchives=https://lists.owasp.org/pipermail/owasp-germany<br />
</span><br />
}}<br />
<br />
==== OWASP German Chapter Sponsorships ====<br />
<br />
<!-- Sponsoren: bitte 3-spaltige Tabelle benutzen, damit genuegend Abstand zwischen den Bildern --><br />
{| width="99%" style="background-color:inherit;"<br />
| [[Image:Schutzwerk-300x29.png|link=http://www.schutzwerk.com|www.schutzwerk.com]]<br />
| [[Image:TC-Logo-mit-Firmennamen-RGB.png|link=http://www.tele-consulting.com|www.tele-consulting.com]]<br />
|-<br />
| [[Image:sicsec_logo_was_OWASP_20121218_small.png|link=http://www.sicsec.de|www.sicsec.de]]<br />
| [[Image:Cyberday-logo_8700px_square.png|link=https://www.cyberday-gmbh.de|www.cyberday-gmbh.de]]<br />
|-<br />
|<br />
|<br />
|<br />
|}<br />
<br />
Unser Angebot an Sponsoren / Offer for Chapter Sponsors: <u>[[Germany/Chaptersponsor|OWASP German Chapter Sponsorship]]</u>.<br />
<br />
<br />
== '''OWASP German Chapter''' ==<br />
<br />
[[File:Logo AppSecEU2013-Nr3backg50.png|798px|center|link=https://owasp.org/index.php/AppSecEU2013|(original photo from IqRS)]]<br />
<!-- Top News: auf hellblauem Hintergrund ganz oben auf der Seite --><br />
<div style="background-color:rgb(153,204,255);margin:2em;padding-left:1em;"><big style="padding:1em;"><br />
Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
<br />
The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
<br />
</big></div><br />
<br />
----<br />
;Mitstreiter: Wir suchen engagierte Personen, die das German Chapter als Ansprechpartner für Firmen und Branchen vertreten. Weitere Details folgen in Kürze hier.<br />
----<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Aktuelles ===<br />
<br />
;22.02.2013: German Chapter Meeting findet am '''17.05.2013''' in Frankfurt statt.<br />
;5.12.2012: Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
: The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
;10.11.2012: <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]:</u> Die hochrangige Websicherheitskonferenz war ein voller Erfolg: Dank gilt allen Besuchern -- gut ein Drittel mehr als letztes Jahr -- Sprechern und Sponsoren.<br />
;07.11.2012: <u>[[Germany/Chaptersponsor|Chapter Sponsorsing]]</u> möglich.<br />
;03.11.2012: Webseite des [[Germany|OWASP German Chapter]] neu strukturiert.<br />
;10.09.2012: <u>[[German_OWASP_Day_2012/Programm|Programm]]</u> für <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u> in München am 7.11.2012 steht<br />
;13.07.2012: Am Ende der AppSecEU 2012 wurde offiziell verkündet, dass das Deutsche Chapter die AppSecEU Research 2013 hostet. Ort Hamburg, Zeit: Juli <br />
;02.05.2012: Call for Presentations offen für <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u>. Ort: München, Zeit: 7.11.2012<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== News ===<br />
(see left side)<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
Ältere Nachrichten sind <u>[[Germany/Aktuelles|hier]]</u> archiviert.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
Old news (what a nice name :-) can be found <u>[[Germany/Aktuelles|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Unsere Konferenzen ===<br />
<br />
;20. - 23.08.2013: Das German Chapter veranstaltet die <u>[[AppSecEU2013|OWASP AppSec Europe Research 2013]]</u>.<br />
;7.11.2012: <u>[[German_OWASP_Day_2012|German OWASP Day 2012]]</u> in München<br />
<br />
Eine Liste aller vom OWASP German Chapter durchgeführten Konferenzen ist <u>[[Germany/Konferenzen|hier]]</u> zu finden.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== German Conferences ===<br />
<br />
;20. - 23.08.2013: The German Chapter is proud announcing <u>[[AppSecEU2013|date and location]]</u> of AppSecEU 2013.<br />
<br />
<br />
A list of conferences organized by the OWASP German Chapter can be found <u>[[Germany/Konferenzen|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Projekte des German Chapter ===<br />
Das German Chapter initiiert oder beteiligt sich an <u>[https://www.owasp.org/index.php/Category:OWASP_Project OWASP Projekten]</u>. Die Liste ist <u>[[Germany/Projekte|hier]]</u> zu finden.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Projects of German Chapter ===<br />
The German Chapter initiated or participated at [https://www.owasp.org/index.php/Category:OWASP_Project OWASP Projects]. A List can be found <u>[[Germany/Projekte|here]]</u>.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== OWASP Stammtisch-Initiative ===<br />
In mehren Städten gibt es <u>[[Germany/Stammtisch_Initiative|OWASP-Stammtisch]]</u>, bei denen man sich in lockerer Runde im Biergarten oder Gasthaus trifft um sich auszutauschen, nette Leute kennenzulernen oder auch ernsthafte Sicherheitsthemen zu diskutieren. <br />
<br />
Aktive Stammtische gibt es (Stand 2011) in:<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |München]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Köln]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== OWASP Regular Tables ===<br />
A "regular's table" (Stammtisch) is a German tradition for meeting each other in a beer garden or a pub in order to discuss certain topics (and to drink beer, of course&nbsp;;-).<br />
<br />
In the case of an <u>[[Germany/Stammtisch_Initiative|OWASP-Stammtisch]]</u> it's all about Web Application Security. Right now a Stammtisch is established in <br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |Munich]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Cologne]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Chapter Meetings ===<br />
;Ankündigung: nächstes Chapter Meeting am '''17.05.2013''' in Frankfurt. Details in Kürze ...<br />
Das German Chapter trifft sich in unregelmäßigen Abständen, um die Arbeit innerhalb des German Chapter zu organisieren.<br />
Gemäß dem ''O'' in OWASP für ''open'' sind diese Treffen öffentlich. Jedermann kann daran teilnehmen und sich ander Arbeit im Chpater beteiligen. Der Termin zum Treffen -- Chapter Meeting -- wird auf dieser Seite bekannt gegegebn, zusammen mit der Agenda. Selbstverständlich sind auch alle Ergebnisse der Treffen öffentlich. Was auf den vergangenen Treffen jeweils besprochen und beschlossen wurde ist auf der <u>[[Germany/Chapter_Meetings|Chapter Meetings]]</u>-Seite zu finden.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Chapter Meetings ===<br />
;Announcement: next Chapter Meeting '''17.05.2013''' in Frankfurt. Details comming soon ...<br />
The German Chapter meetings are anounced here. All oucomes of previous meetings will be found on <br />
<u>[[Germany/Chapter_Meetings|Chapter Meetings]]</u>.<br />
<br />
'''Note''' that this page is in German mainly.<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== So erreichen Sie uns ===<br />
;Twitter: [https://twitter.com/#!/search/OWASP_de Twitter: @OWASP_de] <br />
;Mailing-Liste: <u>[https://lists.owasp.org/mailman/listinfo/owasp-germany owasp-germany@lists.owasp.org]</u> <u>[https://lists.owasp.org/pipermail/owasp-germany Mailarchiv]</u><br />
<br />
Jede Mitarbeit am OWASP German Chapter ist willkommen. Wir freuen uns auf Beiträge in unserer <u>[https://lists.owasp.org/mailman/listinfo/owasp-germany Mailingliste]</u>. Diese sollten natürlich einen Bezug zu (Web-)Anwendungssicherheit haben. Denkbar sind also u. A. Fragen, Tipps, aktuelle Hinweise, Stellenangebote oder Projektgesuche. Es gibt auch ein <u>[https://lists.owasp.org/pipermail/owasp-germany Mailarchiv]</u> von der Liste. Wenn Sie nicht an den Meetings teilnehmen können, kontaktieren Sie einfach einen der German Chapter Board Members (siehe oben) oder schreiben Sie eine E-Mmail an uns [mailto:owasp-germany@lists.owasp.org chapter mailing list].<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
=== Contact us ===<br />
If you want to participate in the work of the OWASP German Chapter or offer to submit work to it and cannot attend the meeting, please contact any of the German Chapter Board members (see above) or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list]. <br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
=== Presse ===<br />
Informationen für die Presse finden sich <u>[[Germany/press|hier]]</u><br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
=== Press Relations ===<br />
Press Relations of the OWASP German Chapter are currently directed exclusively towards the local press. We therefore do not provide english translations.<br />
<br />
* <u>[[Germany/press|Press relations]]</u><br />
|}<br />
<br />
<small>(Kleines [[Germany/Website_HowTo| HowTo]] für die deutschen wiki-Seiten)</small><br />
<br />
[[Category:Germany]] [[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany/Chapter_Meetings&diff=152061Germany/Chapter Meetings2013-05-22T16:27:16Z<p>Kai Jendrian: /* Ergebnisse / Protokoll */</p>
<hr />
<div>__NOTOC__<br />
<br />
[[Image:owasp_germany_logo.png|right]]<br />
<br />
{| width="100%" style="background-color:inherit;border-bottom:1px solid black"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Chapter Meetings ===<br />
Hier sind Informationen zu den Treffen des German Chapter -- Chapter Meeting -- zu finden. Die Agenda, Einladung sowie die erarbeiteten Ergebnisse werden hier veröffentlicht.<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Chapter Meetings ===<br />
This page contains all informations about Chapter Meetings of the OWASP German Chapter.<br />
<br />
Please note, that most informations are in German only.<br />
|}<br />
<br />
==OWASP Germany Chapter Meeting am 17.05.2013 in Frankfurt==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
Das OWASP Germany Chapter Meeting findet am 17.05.2012 um 14 Uhr in Frankfurt statt.<br />
<br />
Ort: Saalbau Gallus, Frankenallee 111, 60326 Frankfurt am Main <br />
[[http://maps.google.de/maps?q=Frankenallee+111,+60326+Frankfurt+am+Main&hl=de&sll=50.104389,8.642389&sspn=0.002883,0.010375&vpsrc=0 Karte]] (Wenige Meter von der S-Bahnstation Galluswarte entfernt, ein Halt von Frankfurt Hbf)<br />
----<br />
==== Einladung ====<br />
Hiermit laden wir Euch nochmals herzlich zum Chapter Meeting des OWASP German Chapters ein.<br />
<br />
Wer sich aktiv in die Gestaltung des Chapters einbringen möchte, ist hier genau richtig. Die Chapter-Meetings richten sich an all diejenigen, die aktiv am Chapter geschehen teilhaben möchten. Wir stellen die Weichen, um OWASP in Deutschland noch präsenter zu machen und freuen uns auf Deinen Beitrag! OWASP lebt von der Community, von der aktiven Beteiligung.<br />
<br />
[[https://reg.owasp.de Meldet Euch bitte hier an]]. Bitte!<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
|-<br />
| style="vertical-align:top;" |<br />
==== Agenda ====<br />
<br />
* 14.00h Tobias Glemser, OWASP German Chapter Lead (30 min): Warme Willkommensworte und Rückblick auf Chapter-Aktivitäten 2012 <br />
* 14:30h Laurent Levi von Checkmarx (45 min): DevOps and Security: It's Happening. Right Now.<br />
* 15:15h Dirk Wetter, OWASP German Chapter Board Member und AppSec EU Research Conference Chair (30 min): Rückblick OWASP Day 2012 und Ausblick AppSec EU Research 2013 <br />
* 15:45h Pause (15 min) <br />
* 16.00h Jim Manico, OWASP Board Member (45 min): Top Ten Web Defenses<br />
* 16.45h Torsten Gigler, OWASP German Chapter (15 min): [[https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 fuer Entwickler]]<br />
* 17.00h Tobias Glemser, OWASP German Chapter Lead (15 min): Chapter Board Wahl <br />
* 17.15h offene Runde (30 min): OWASP Germany im kommenden Jahr <br />
* Gegen 17.30 Uhr Ende und wer mag im Anschluss noch einen Absacker im benachbarten Griechen.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
* 14.00h Tobias Glemser, OWASP German Chapter Lead (30 min): Welcome and Review of Chapter Activities 2012 <br />
* 14:30h Laurent Levi von Checkmarx (45 min): DevOps and Security: It's Happening. Right Now.<br />
* 15:15h Dirk Wetter, OWASP German Chapter Board Member und AppSec EU Research Conference Chair (30 min): Review OWASP Day 2012 and Outlook AppSec EU Research 2013 <br />
* 15:45h Break (15 min) <br />
* 16.00h Jim Manico, OWASP Board Member (45 min): Top Ten Web Defenses<br />
* 16.45h Torsten Gigler, OWASP German Chapter (15 min): [[https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 fuer Entwickler]]<br />
* 17.00h Tobias Glemser, OWASP German Chapter (15 min): Chapter Board Election<br />
* 17.00h offene Runde (30 min): OWASP Germany next year <br />
* About 17.30h we will be finished. Who's interested in joining a get together in a greek restaurant nearby is asked to note <br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
<br />
<br />
* Begrüßung und Bericht durch Tobias<br />
* Talk: Laurent Levi, Checkmarx<br />
* Kurze Vorstellungsrunde<br />
* Talk: Torsten Gigler - OWASP Top 10 für Entwickler<br />
* Talk: Dirk Wetter - AppSec Research 2013<br />
** GOD 2012<br />
*** Rückblick auf GOD 2012 (German OWASP Day)<br />
*** Fachlich und finanziell ein voller Erfolg<br />
** Dev(i|e)l 2013<br />
*** Ausblick auf AppSec Research 2013<br />
*** Konferenz verspricht viel<br />
*** Details unter [https://appsec.eu](https://appsec.eu)<br />
* Talk: Jim Manico<br />
* Organisatorisches<br />
** Chapter Lead: Tobias Glemser<br />
** Board 2013: <br />
*** Dirk Wetter<br />
*** Martin Johns <br />
*** Achim Hoffmann<br />
*** Emin Tatli <br />
*** Kai Jendrian<br />
** Entscheidung: Neubesetzung des Boards jährlich <br />
* OWASP Day 2014<br />
* Ortsauswahl durch Call for Venue<br />
* Vorschläge vor Ort:<br />
** Köln<br />
** Karlsruhe<br />
* Vorschläge Projekte<br />
** Übersetzug OpenSAMM<br />
** Übersetzung der Top 10 nach finaler Veröffentlichung (Trigger durch Kai)<br />
* Sonstiges:<br />
** Treffen des OWASP Chapters im Q4 mit Vortrag<br />
** Bessere Präsenz der OWASP in andere Konferenzen<br />
<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
==== Protocol ====<br />
tbd<br />
|<br />
<br />
|-<br />
! colspan="2" align="left" style="vertical-align:top;" |<br />
==== Abstracts/Bios ====<br />
|-<br />
| colspan="2" |<br />
===== DevOps and Security: It's Happening. Right Now. =====<br />
How do you integrate security within a Continuous Deployment (CD) environment - where every 5 minutes a feature, an enhancement, or a bug fix needs to be released? Traditional application security tools which require lengthy periods of configuration, tuning and application learning have become irrelevant in these fast-pace environments. Yet, falling back only on the secure coding practices of the developer cannot be tolerated. <br />
Secure coding requires a new approach where security tools become part of the development environment – and eliminate any unnecessary code analysis overhead. By collaborating with development teams, understanding their needs and requirements, you can pave the way to a secure deployment in minutes. Steps include: <br />
* Re-evaluate existing security tools and consider their integration within a CD environment<br />
* Deliver a secured development framework and enforce its usage<br />
* Pinpoint precise security code flaws and provide optimal fix recommendations<br />
<br />
Laurent Levi<br />
Laurent is an experienced security professional with extensive technical knowledge in all aspects of application security. Over the last 6 years, Laurent has been managing Checkmarx's professional services team and prior to that led the code audit team of Lexsi in France. Laurent has extensive software development experience and has a post graduate degree in AI from Paris VI Université Pierre et Marie Curie.<br />
<br />
===== Top Ten Web Defenses =====<br />
We cannot “firewall” or “patch” our way to secure websites. In the past, security professionals thought firewalls, Secure Sockets Layer (SSL), patching, and privacy policies were enough. Today, however, these methods are outdated and ineffective, as attacks on prominent, well-protected websites are occurring every day. Citigroup, PBS, Sega, Nintendo, Gawker, AT&T, the CIA, the US Senate, NASA, Nasdaq, the NYSE, Zynga, and thousands of others have something in common – all have had websites compromised in the last year. No company or industry is immune. Programmers need to learn to build websites differently. This talk will review the top coding techniques developers need to master in order to build a low-risk, high-security web application.<br />
<br />
Jim Manico is the VP of Security Architecture for WhiteHat Security, a web security firm. He authors and delivers developer security awareness training for WhiteHat Security and has a background as a software developer and architect. Jim is also a global board member for the OWASP foundation. He manages and participates in several OWASP projects, including the OWASP cheat sheet series and the OWASP podcast series.<br />
----<br />
|}<br />
<br />
==OWASP Germany Chapter Meeting am 03.02.2012 in Frankfurt==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
OWASP Germany Chapter Meeting fand am 03.02.2012 in Frankfurt statt.<br />
<br />
Ort: Saalbau Gallus, Frankenallee 111, 60326 Frankfurt am Main <br />
[[http://maps.google.de/maps?q=Frankenallee+111,+60326+Frankfurt+am+Main&hl=de&sll=50.104389,8.642389&sspn=0.002883,0.010375&vpsrc=0 Karte]] (Wenige Meter von der S-Bahnstation Galluswarte entfernt, ein Halt von<br />
Frankfurt Hbf)<br />
----<br />
==== Einladung ====<br />
Hiermit laden wir Euch nochmals herzlich zum ersten Chapter Meeting 2012 des OWASP German Chapters ein.<br />
Wer sich aktiv in die Gestaltung des Chapters einbringen möchte, ist hier genau richtig. Wir stellen die Weichen, um OWASP in Deutschland noch präsenter zu machen und freuen uns auf Deinen Beitrag! OWASP lebt von der Community, von der aktiven Beteiligung.<br />
Nur aufgrund der vielen Köpfe sind wir dort, wo wir heute stehen. Also los! Wir würden uns insbesondere freuen, mehr von Euch aus dem edukativen Bereich (ja, Ihr liebe Studenten!) bei uns willkommen zu heißen.<br />
<br />
Zur besseren Planung gebt bitte kurz per Mail Bescheid, wenn Ihr teilnehmt. Danke!<br />
<br />
Plant auch danach noch gerne etwas Zeit ein, wir lassen den Tag bei einem gemeinsamen Essen und vielleicht einem Getränk nachwirken.<br />
<br />
Viele Grüße und bis zum 03.02. in Frankfurt, wir freuen uns auf Euch.<br />
OWASP German Chapter<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
|-<br />
|<br />
==== Agenda ====<br />
<br />
* Georg: Begrüßung durch Georg Heß, German Board Leader<br />
* Kai: Vortrag "OWASP Top 10 auf Deutsch - Fallstricke und Überraschungen"<br />
* Kai: Fragen und Antworten zu "OWASP Top 10 auf Deutsch"<br />
* Boris: Vortrag "Das neue OWASP Chapter Handbook - wie wir weltweit arbeiten"<br />
* Boris: Fragen und Antworten zu "OWASP Chapter Handbook"<br />
* Dirk: Rückblick OWASP Day 2011, Ausblick 2012<br />
* Tobias: Rückblick it-sa 2011, Ausblick 2012<br />
* Dirk: AppSec Research EU: 2013 in Deutschland?<br />
* Boris: Firmen-Chapter-Support (Kosten, Vorteile, Ablauf)<br />
* Georg: Aktionen zur Mitgliedergewinnung<br />
* Bruce: Möglichkeiten zur Intensivierung der Pressearbeit<br />
* Boris: Zusammenarbeit mit dem BSI<br />
* Tobias: Themen für Projekte 2012<br />
* Georg: kurzer Abriss zu OWASP-Zertifizierungen<br />
* Achim: Definition Rahmenbedingungen Jobseite<br />
* Achim: Administratoren für owasp.org<br />
* Georg: Wahl Leader und Board OWASP German Chapter<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
Das Protokoll des Chapter-Meetings ist <u>[[Media:Chapter-Germany-20120203-Protokoll.zip|hier]]</u> zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* Tobias als Chapter Leader gewählt<br />
* Wahl des Boards: Bruce, Dirk, Emin, Martin, Achim<br />
* German OWASP Day 2012 im November in München<br />
** 1,5 - 2 Tage, dieses Jahr keine kommerziellen Trainings<br />
** CfP-Kommitee geführt von Dirk, Martin<br />
** es wird eine Teilnahme/Anwesenheits-Bescheinigung geben<br />
* OWASP-Stand auf it.sa 2012 in Nürnberg<br />
* Firmensponsoring wird ermöglicht: local sponsor ca. 500,-/Jahr<br />
* Zusammenarbeit mit BSI wird intensiviert<br />
* es wird (vorerst) keine eigene deutsche Jobseite unter owasp.org geben; bitte [[OWASP_Jobs]] benutzen<br />
...<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Meetings minutes can be found <u>[[Media:Chapter-Germany-20120203-Protokoll.zip|here]]</u> . Note that it is in German.<br />
<br />
Most important:<br />
* Tobias as Chapter Leader elected<br />
* Boards Members: Bruce, Dirk, Emin, Martin, Achim<br />
* German OWASP Day 2012 will be in November in München<br />
** 1,5 - 2 days, no trainings sessions this year<br />
** CfP Commitee lead by Dirk, Martin<br />
* OWASP will be present at it.sa 2012 in Nürnberg<br />
* company sponsoring possible: local sponsor ca. 500,-/anno<br />
* co-operation and collaboration with BSI will be initiated<br />
* currently no local job page within owasp.org<br />
...<br />
|}<br />
<br />
==Chapter Board Meeting am 19.8.2011 in München==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* Selbstverständnis Chapter – die Zukunft<br />
* OWASP Germany in „das Bewusstsein“ bringen<br />
* Vereinsgründung ja/nein<br />
* Geldverwaltung/Rechnungen<br />
* Firmen als Chapter Member<br />
* IT-SA 2011<br />
* Board (Kommunikation. Rollen, Wahl, Termin Chapter Meeting)<br />
* Stand der Dinge: Flyer<br />
* OWASP Day<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
Das Protokoll des Board-Meetings ist <u>[[Media:Chapter-Germany-20110819-Protokoll.zip|hier]]</u> zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* OWASP Chapter Germany stellt auf der it.sa in Nürnberg aus, 11.10. - 13.10.2011<br />
* es wird eine ''Firmen-Mitgliedschaft'' aka ''Chapter Supporter'' angeboten; Näheres in kürze auf der Webseite<br />
* nächstes Chapter Meeting am 20.01.2012 oder 03.02.2012 in Frankfurt<br />
...<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
==== Protocol ====<br />
The protocol of the Chapter Germany Board Meetings can be found <u>[[Media:Chapter-Germany-20110819-Protokoll.zip|here]]</u> . Note that it is in German.<br />
<br />
Most important:<br />
* OWASP Chapter Germany will be at it.sa in Nuremberg, 11.10. - 13.10.2011<br />
* ''Chapter Supporter'' will be possible for companies; details comming soon<br />
* next Chapter Meeting 20.01.2012 or 03.02.2012 in Frankfurt<br />
...<br />
|}<br />
<br />
== Chapter Meeting am 20.5.2010 in München ==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* 14:00 Allgemeine Begrüßungs- und Vorstellungsrunde <br />
* 14:15 Bruce Sams: „Strategie und Kosten für ein SDLC“ <br />
* 14:50 Diskussion <br />
* 15:10 Boris Hemkemeier: „Two Factors Are Not Enough“ <br />
* 16:05 Diskussion (geht nahtlos über in die) <br />
* 16:15 Kaffeepause <br />
* 16:35 Vortrag mit Diskussion „Organisatorisches im Chapter“ <br />
* 17:15 Beginn der Beschlussfassungen und Wahlen <br />
* 17:25 Vortrag mit Diskussion „OWASP Germany Conference 2010“ <br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
===== Organisatorisches im Chapter =====<br />
<br />
Die Wesentlichen Punkte, die umgesetzt oder verbessert werden sollen: <br />
<br />
* Mehr Außenwirkung durch Public Relations, bessere Pressearbeit / Pressemitteilungen und Einführung und Pflege einer Sprecher- und Rednerliste (um z.B. bei öffentlichen Veranstaltungen OWASP adäquat vorstellen zu können) <br />
* Gepflegtes Wiki sowohl für Außendarstellung als auch als Plattform für die interne Kommunikation <br />
* Einführung von direkten Ansprechpartner für diverse Branchen<br />
<br />
Es folgt eine kurze Diskussion, wie dies effektiv umgesetzt werden kann. Es wird ein Vorschlag durch konkludentes Handeln angenommen: Es soll ein Chapter Board bestehend aus 5 Mitgliedern gewählt werden. Jedes dieser Mitglieder bekommt eine oder mehrere dedizierte Aufgabe(n), um die oben genannten Punkte abzudecken und umzusetzen. Es folgt ein Aufruf, sich für eine entsprechende Wahl zur Verfügung zu stellen. Es soll ebenso der neue Chapter Leader gewählt werden. Da sich nur ein Kandidat für nur einen Posten zur Wahl für die nächsten zwei Jahre zur Verfügung stellt, wird folgendes entschieden: Bei Abstimmungen hat jedes Mitglied des Boards genau eine Stimme, während der Chapter Leader zwei Stimmen hat. So soll zukünftig bei Abstimmungen eine Stimmengleichheit verhindert werden. <br />
<br />
===== Beschluss zur Anzahl der Chapter Leaders =====<br />
<br />
Es wird von den 12 Teilnehmern des Chapter Meetings einstimmig beschlossen, das zukünftig das Chapter Germany (analog zu den meisten anderen OWASP Chapters) nur noch einen Chapter Leader hat. <br />
<br />
===== Wahl des Chapter Leaders =====<br />
<br />
''Georg Heß'' kandidiert als Chapter Leader und wird mit 11 von 12 Stimmen bei einer Enthaltung zum neuen Chapter Leader des OWASP Chapters Germany gewählt. <br />
<br />
===== Beschluss zur zukünftigen Zusammensetzung des Boards =====<br />
<br />
Einstimmig wird beschlossen, dass das zukünftige Board aus 5 Mitgliedern besteht. Diese sollen die Aufgaben wie in der Diskussion beschrieben wahr nehmen. <br />
<br />
===== Wahl des Boards =====<br />
<br />
Es kandidieren ''Tobias Glemser, Boris Hemkemeier, Achim Hoffmann, Uli Petersen und Bruce Sams'' für die 5 Sitze im Board. Alle werden einstimmig gewählt. <br />
<br />
Alle Gewählten nehmen die Wahl an. <br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Not yet available in English, sorry.<br />
|}<br />
<br />
<br />
== OWASP German Chapter Meeting 10.07.2009, Mannheim ==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Einladaung ====<br />
;Summary:We will start with three interesting fresh talks. The following topics are the next activities of the OWASP German Chapter: the new [http://www.owasp.org/index.php/OWASP_German_Chapter_Stammtisch_Initiative "Stammtisch Initiative"] and the planning of the [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009] at Nuremberg. <br />
<br />
;Location:Aula of the [http://www.hs-mannheim.de Hochschule Mannheim], Building 3, Paul-Wittsack-Strasse 10, Mannheim ([http://maps.google.de/maps?f=d&source=s_d&saddr=Mannheim+Hbf&daddr=49.471303,8.48372&geocode=Fbr-8gIduTmBAA%3B&hl=de&mra=dme&mrcr=0&mrsp=1&sz=15&sll=49.474885,8.474715&sspn=0.015532,0.050254&ie=UTF8&z=15 Google Maps]). Please download the [http://www.hs-mannheim.de/campus/grafik/campusplan_legende_web.pdf campus map]. <br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Invitation ====<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* 12:00 - 13:00&nbsp;: Lunch (optional, please send an email to [mailto:Georg.Hess@artofdefence.com?subject=OWASP%20Chapter%20Meeting%20Lunch%20registration Georg Heß] to register for lunch), meeting point for the lunch is at the Aula in Building 3<br />
* 13:15 - 13:30 : Opening by our host Prof. Rainer Gerten (German) <br />
* 13:30 - 14:30 : OWASP Educational Services - Teaching Security!, Martin Knobloch, Member of OWASP Global Education Committee (English) <br />
* 14:30 - 15:00 : Vorstellung und aktueller Stand des OWASP Germany Projekts "Best Practice: Projektierung von Sicherheitsprüfungen von Web Applikationen", N.N., Projekt-Mitarbeiter (German) <br />
* 15:00 - 15:45 : Cloud Application Security - Chancen und Risiken - Einige Ansatzpunkte zum Thema, Georg Hess (German) <br />
* 15:45 - 16:15 : Coffee <br />
* 16:15 - 17:00 : Organisational topics of the OWASP German Chapter (German) <br />
** OWASP Stammtisch Initiative <br />
** Outlook and organisational tasks for the 2nd [[OWASP Germany 2009 Conference]]<br />
* nach 17:00 : Come together (Any ideas for a near pub??) <br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
<br />
===== OWASP AppSec 2010 =====<br />
<br />
Es folgt ein kurzer historischer Rückblick der Veranstaltungsorte: 2008 im Hotel in Frankfurt, 2009 auf der Messe it-sa in Nürnberg. Kurze Diskussion pro und contra Hotel vs. Messe vs. Hochschul-Location. <br />
<br />
* Es soll geprüft werden, ob die diesjährige '''„OWASP Germany Conference 2010“''' wieder in Kooperation mit der Messe Nürnberg / it-sa durchgeführt werden kann (z.B. am 20.10.2010). <br />
* Weiterhin ist ein Konferenztag mit '''zwei verschiedenen Tracks (Technik und Management)''' angedacht. <br />
* Um die inhaltliche Gestaltung voranzutreiben wird ein '''Programm-Komitee''' (initial bestehend aus ''Bruce Sams, Kai Jendrian, Boris Hemkemeier und Martin Johns'') ins Leben gerufen, das alsbald den '''CFP''' starten soll.<br />
<br />
Gegen 18:15 löst sich das OWASP German Chapter Meeting auf und geht nahtlos in den 12. „Happy Anniversary!“ OWASP Stammtisch München über.<br />
<br />
Weitere Ergebnisse sind [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html in den Minutes hier] zu finden<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Minutes: [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html See the list archive for the minutes.]<br />
|}<br />
<br />
== OWASP German Chapter Meeting - February 20th, 2008 in Darmstadt ==<br />
<br />
;Date: February 20th, 2008, 11:00-16:15<br />
;Location: The next chapter meeting will be hosted at CAST in Darmstadt.<br />
: CAST (http://www.cast-forum.de)'''<br> Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt]<br />
<br />
;Agenda: This time the focus is on technical presentations and discussion.<br />
: Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion. <br />
# (11:00 - 11:15) Welcome, Introduction and Administrativia <br />
# (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann) <br />
# (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom) <br />
# (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Slides: [http://www.owasp.org/images/1/1b/WAF-Paper.pdf PDF]) (Alexander Meisel) <br />
# (12:30 - 13:15) Break <br />
# (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann) <br />
# (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss) <br />
: * "Input validation in ASP.NET -- tips, tricks &amp; pitfalls" (Boris Hemkemeier) <br />
: * "Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel) <br />
# (14:45 - 15:00) Coffee Break <br />
# (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias) <br />
# (15:45 - 16:00) Wrap-up and outlook<br />
<br />
== Chapter Meeting on September 7th 2007 in Frankfurt/Main ==<br />
<br />
After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00. <br />
<br />
This first chapter meeting had as its main goal the re-initiation of the German chapter and to start work on projects. Talks and presentations are secondary and will receive more focus at subsequent meetings. <br />
<br />
Read meeting notes/minutes [https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html here].<br />
<br />
<br />
----<br />
[[Germany|<top>]]<br />
<br />
[[Category:Germany]] [[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany/Chapter_Meetings&diff=152060Germany/Chapter Meetings2013-05-22T16:25:37Z<p>Kai Jendrian: /* Ergebnisse / Protokoll */</p>
<hr />
<div>__NOTOC__<br />
<br />
[[Image:owasp_germany_logo.png|right]]<br />
<br />
{| width="100%" style="background-color:inherit;border-bottom:1px solid black"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
<br />
=== Chapter Meetings ===<br />
Hier sind Informationen zu den Treffen des German Chapter -- Chapter Meeting -- zu finden. Die Agenda, Einladung sowie die erarbeiteten Ergebnisse werden hier veröffentlicht.<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
=== Chapter Meetings ===<br />
This page contains all informations about Chapter Meetings of the OWASP German Chapter.<br />
<br />
Please note, that most informations are in German only.<br />
|}<br />
<br />
==OWASP Germany Chapter Meeting am 17.05.2013 in Frankfurt==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
Das OWASP Germany Chapter Meeting findet am 17.05.2012 um 14 Uhr in Frankfurt statt.<br />
<br />
Ort: Saalbau Gallus, Frankenallee 111, 60326 Frankfurt am Main <br />
[[http://maps.google.de/maps?q=Frankenallee+111,+60326+Frankfurt+am+Main&hl=de&sll=50.104389,8.642389&sspn=0.002883,0.010375&vpsrc=0 Karte]] (Wenige Meter von der S-Bahnstation Galluswarte entfernt, ein Halt von Frankfurt Hbf)<br />
----<br />
==== Einladung ====<br />
Hiermit laden wir Euch nochmals herzlich zum Chapter Meeting des OWASP German Chapters ein.<br />
<br />
Wer sich aktiv in die Gestaltung des Chapters einbringen möchte, ist hier genau richtig. Die Chapter-Meetings richten sich an all diejenigen, die aktiv am Chapter geschehen teilhaben möchten. Wir stellen die Weichen, um OWASP in Deutschland noch präsenter zu machen und freuen uns auf Deinen Beitrag! OWASP lebt von der Community, von der aktiven Beteiligung.<br />
<br />
[[https://reg.owasp.de Meldet Euch bitte hier an]]. Bitte!<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
|-<br />
| style="vertical-align:top;" |<br />
==== Agenda ====<br />
<br />
* 14.00h Tobias Glemser, OWASP German Chapter Lead (30 min): Warme Willkommensworte und Rückblick auf Chapter-Aktivitäten 2012 <br />
* 14:30h Laurent Levi von Checkmarx (45 min): DevOps and Security: It's Happening. Right Now.<br />
* 15:15h Dirk Wetter, OWASP German Chapter Board Member und AppSec EU Research Conference Chair (30 min): Rückblick OWASP Day 2012 und Ausblick AppSec EU Research 2013 <br />
* 15:45h Pause (15 min) <br />
* 16.00h Jim Manico, OWASP Board Member (45 min): Top Ten Web Defenses<br />
* 16.45h Torsten Gigler, OWASP German Chapter (15 min): [[https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 fuer Entwickler]]<br />
* 17.00h Tobias Glemser, OWASP German Chapter Lead (15 min): Chapter Board Wahl <br />
* 17.15h offene Runde (30 min): OWASP Germany im kommenden Jahr <br />
* Gegen 17.30 Uhr Ende und wer mag im Anschluss noch einen Absacker im benachbarten Griechen.<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
* 14.00h Tobias Glemser, OWASP German Chapter Lead (30 min): Welcome and Review of Chapter Activities 2012 <br />
* 14:30h Laurent Levi von Checkmarx (45 min): DevOps and Security: It's Happening. Right Now.<br />
* 15:15h Dirk Wetter, OWASP German Chapter Board Member und AppSec EU Research Conference Chair (30 min): Review OWASP Day 2012 and Outlook AppSec EU Research 2013 <br />
* 15:45h Break (15 min) <br />
* 16.00h Jim Manico, OWASP Board Member (45 min): Top Ten Web Defenses<br />
* 16.45h Torsten Gigler, OWASP German Chapter (15 min): [[https://www.owasp.org/index.php/OWASP_Top_10_Fuer_Entwickler_Project OWASP Top 10 fuer Entwickler]]<br />
* 17.00h Tobias Glemser, OWASP German Chapter (15 min): Chapter Board Election<br />
* 17.00h offene Runde (30 min): OWASP Germany next year <br />
* About 17.30h we will be finished. Who's interested in joining a get together in a greek restaurant nearby is asked to note <br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
<br />
<br />
* Begrüßung und Bericht durch Tobias<br />
<br />
* Talk: Laurent Levi, Checkmarx<br />
<br />
* Kurze Vorstellungsrunde<br />
<br />
* Talk: Torsten Gigler - OWASP Top 10 für Entwickler<br />
<br />
* Talk: Dirk Wetter - AppSec Research 2013<br />
<br />
** GOD 2012<br />
*** Rückblick auf GOD 2012 (German OWASP Day)<br />
*** Fachlich und finanziell ein voller Erfolg<br />
<br />
** Dev(i|e)l 2013<br />
*** Ausblick auf AppSec Research 2013<br />
*** Konferenz verspricht viel<br />
*** Details unter [https://appsec.eu](https://appsec.eu)<br />
<br />
* Talk: Jim Manico<br />
<br />
* Organisatorisches<br />
<br />
** Chapter Lead: Tobias Glemser<br />
** Board 2013: <br />
*** Dirk Wetter<br />
*** Martin Johns <br />
*** Achim Hoffmann<br />
*** Emin Tatli <br />
*** Kai Jendrian<br />
<br />
** Entscheidung: Neubesetzung des Boards jährlich <br />
<br />
<br />
* OWASP Day 2014<br />
<br />
* Ortsauswahl durch Call for Venue<br />
* Vorschläge vor Ort:<br />
** Köln<br />
** Karlsruhe<br />
<br />
* Vorschläge Projekte<br />
<br />
** Übersetzug OpenSAMM<br />
** Übersetzung der Top 10 nach finaler Veröffentlichung (Trigger durch Kai)<br />
<br />
* Sonstiges:<br />
** Treffen des OWASP Chapters im Q4 mit Vortrag<br />
** Bessere Präsenz der OWASP in andere Konferenzen<br />
<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
==== Protocol ====<br />
tbd<br />
|<br />
<br />
|-<br />
! colspan="2" align="left" style="vertical-align:top;" |<br />
==== Abstracts/Bios ====<br />
|-<br />
| colspan="2" |<br />
===== DevOps and Security: It's Happening. Right Now. =====<br />
How do you integrate security within a Continuous Deployment (CD) environment - where every 5 minutes a feature, an enhancement, or a bug fix needs to be released? Traditional application security tools which require lengthy periods of configuration, tuning and application learning have become irrelevant in these fast-pace environments. Yet, falling back only on the secure coding practices of the developer cannot be tolerated. <br />
Secure coding requires a new approach where security tools become part of the development environment – and eliminate any unnecessary code analysis overhead. By collaborating with development teams, understanding their needs and requirements, you can pave the way to a secure deployment in minutes. Steps include: <br />
* Re-evaluate existing security tools and consider their integration within a CD environment<br />
* Deliver a secured development framework and enforce its usage<br />
* Pinpoint precise security code flaws and provide optimal fix recommendations<br />
<br />
Laurent Levi<br />
Laurent is an experienced security professional with extensive technical knowledge in all aspects of application security. Over the last 6 years, Laurent has been managing Checkmarx's professional services team and prior to that led the code audit team of Lexsi in France. Laurent has extensive software development experience and has a post graduate degree in AI from Paris VI Université Pierre et Marie Curie.<br />
<br />
===== Top Ten Web Defenses =====<br />
We cannot “firewall” or “patch” our way to secure websites. In the past, security professionals thought firewalls, Secure Sockets Layer (SSL), patching, and privacy policies were enough. Today, however, these methods are outdated and ineffective, as attacks on prominent, well-protected websites are occurring every day. Citigroup, PBS, Sega, Nintendo, Gawker, AT&T, the CIA, the US Senate, NASA, Nasdaq, the NYSE, Zynga, and thousands of others have something in common – all have had websites compromised in the last year. No company or industry is immune. Programmers need to learn to build websites differently. This talk will review the top coding techniques developers need to master in order to build a low-risk, high-security web application.<br />
<br />
Jim Manico is the VP of Security Architecture for WhiteHat Security, a web security firm. He authors and delivers developer security awareness training for WhiteHat Security and has a background as a software developer and architect. Jim is also a global board member for the OWASP foundation. He manages and participates in several OWASP projects, including the OWASP cheat sheet series and the OWASP podcast series.<br />
----<br />
|}<br />
<br />
==OWASP Germany Chapter Meeting am 03.02.2012 in Frankfurt==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
OWASP Germany Chapter Meeting fand am 03.02.2012 in Frankfurt statt.<br />
<br />
Ort: Saalbau Gallus, Frankenallee 111, 60326 Frankfurt am Main <br />
[[http://maps.google.de/maps?q=Frankenallee+111,+60326+Frankfurt+am+Main&hl=de&sll=50.104389,8.642389&sspn=0.002883,0.010375&vpsrc=0 Karte]] (Wenige Meter von der S-Bahnstation Galluswarte entfernt, ein Halt von<br />
Frankfurt Hbf)<br />
----<br />
==== Einladung ====<br />
Hiermit laden wir Euch nochmals herzlich zum ersten Chapter Meeting 2012 des OWASP German Chapters ein.<br />
Wer sich aktiv in die Gestaltung des Chapters einbringen möchte, ist hier genau richtig. Wir stellen die Weichen, um OWASP in Deutschland noch präsenter zu machen und freuen uns auf Deinen Beitrag! OWASP lebt von der Community, von der aktiven Beteiligung.<br />
Nur aufgrund der vielen Köpfe sind wir dort, wo wir heute stehen. Also los! Wir würden uns insbesondere freuen, mehr von Euch aus dem edukativen Bereich (ja, Ihr liebe Studenten!) bei uns willkommen zu heißen.<br />
<br />
Zur besseren Planung gebt bitte kurz per Mail Bescheid, wenn Ihr teilnehmt. Danke!<br />
<br />
Plant auch danach noch gerne etwas Zeit ein, wir lassen den Tag bei einem gemeinsamen Essen und vielleicht einem Getränk nachwirken.<br />
<br />
Viele Grüße und bis zum 03.02. in Frankfurt, wir freuen uns auf Euch.<br />
OWASP German Chapter<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
|-<br />
|<br />
==== Agenda ====<br />
<br />
* Georg: Begrüßung durch Georg Heß, German Board Leader<br />
* Kai: Vortrag "OWASP Top 10 auf Deutsch - Fallstricke und Überraschungen"<br />
* Kai: Fragen und Antworten zu "OWASP Top 10 auf Deutsch"<br />
* Boris: Vortrag "Das neue OWASP Chapter Handbook - wie wir weltweit arbeiten"<br />
* Boris: Fragen und Antworten zu "OWASP Chapter Handbook"<br />
* Dirk: Rückblick OWASP Day 2011, Ausblick 2012<br />
* Tobias: Rückblick it-sa 2011, Ausblick 2012<br />
* Dirk: AppSec Research EU: 2013 in Deutschland?<br />
* Boris: Firmen-Chapter-Support (Kosten, Vorteile, Ablauf)<br />
* Georg: Aktionen zur Mitgliedergewinnung<br />
* Bruce: Möglichkeiten zur Intensivierung der Pressearbeit<br />
* Boris: Zusammenarbeit mit dem BSI<br />
* Tobias: Themen für Projekte 2012<br />
* Georg: kurzer Abriss zu OWASP-Zertifizierungen<br />
* Achim: Definition Rahmenbedingungen Jobseite<br />
* Achim: Administratoren für owasp.org<br />
* Georg: Wahl Leader und Board OWASP German Chapter<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
Das Protokoll des Chapter-Meetings ist <u>[[Media:Chapter-Germany-20120203-Protokoll.zip|hier]]</u> zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* Tobias als Chapter Leader gewählt<br />
* Wahl des Boards: Bruce, Dirk, Emin, Martin, Achim<br />
* German OWASP Day 2012 im November in München<br />
** 1,5 - 2 Tage, dieses Jahr keine kommerziellen Trainings<br />
** CfP-Kommitee geführt von Dirk, Martin<br />
** es wird eine Teilnahme/Anwesenheits-Bescheinigung geben<br />
* OWASP-Stand auf it.sa 2012 in Nürnberg<br />
* Firmensponsoring wird ermöglicht: local sponsor ca. 500,-/Jahr<br />
* Zusammenarbeit mit BSI wird intensiviert<br />
* es wird (vorerst) keine eigene deutsche Jobseite unter owasp.org geben; bitte [[OWASP_Jobs]] benutzen<br />
...<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Meetings minutes can be found <u>[[Media:Chapter-Germany-20120203-Protokoll.zip|here]]</u> . Note that it is in German.<br />
<br />
Most important:<br />
* Tobias as Chapter Leader elected<br />
* Boards Members: Bruce, Dirk, Emin, Martin, Achim<br />
* German OWASP Day 2012 will be in November in München<br />
** 1,5 - 2 days, no trainings sessions this year<br />
** CfP Commitee lead by Dirk, Martin<br />
* OWASP will be present at it.sa 2012 in Nürnberg<br />
* company sponsoring possible: local sponsor ca. 500,-/anno<br />
* co-operation and collaboration with BSI will be initiated<br />
* currently no local job page within owasp.org<br />
...<br />
|}<br />
<br />
==Chapter Board Meeting am 19.8.2011 in München==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* Selbstverständnis Chapter – die Zukunft<br />
* OWASP Germany in „das Bewusstsein“ bringen<br />
* Vereinsgründung ja/nein<br />
* Geldverwaltung/Rechnungen<br />
* Firmen als Chapter Member<br />
* IT-SA 2011<br />
* Board (Kommunikation. Rollen, Wahl, Termin Chapter Meeting)<br />
* Stand der Dinge: Flyer<br />
* OWASP Day<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
Das Protokoll des Board-Meetings ist <u>[[Media:Chapter-Germany-20110819-Protokoll.zip|hier]]</u> zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* OWASP Chapter Germany stellt auf der it.sa in Nürnberg aus, 11.10. - 13.10.2011<br />
* es wird eine ''Firmen-Mitgliedschaft'' aka ''Chapter Supporter'' angeboten; Näheres in kürze auf der Webseite<br />
* nächstes Chapter Meeting am 20.01.2012 oder 03.02.2012 in Frankfurt<br />
...<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
<br />
==== Protocol ====<br />
The protocol of the Chapter Germany Board Meetings can be found <u>[[Media:Chapter-Germany-20110819-Protokoll.zip|here]]</u> . Note that it is in German.<br />
<br />
Most important:<br />
* OWASP Chapter Germany will be at it.sa in Nuremberg, 11.10. - 13.10.2011<br />
* ''Chapter Supporter'' will be possible for companies; details comming soon<br />
* next Chapter Meeting 20.01.2012 or 03.02.2012 in Frankfurt<br />
...<br />
|}<br />
<br />
== Chapter Meeting am 20.5.2010 in München ==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* 14:00 Allgemeine Begrüßungs- und Vorstellungsrunde <br />
* 14:15 Bruce Sams: „Strategie und Kosten für ein SDLC“ <br />
* 14:50 Diskussion <br />
* 15:10 Boris Hemkemeier: „Two Factors Are Not Enough“ <br />
* 16:05 Diskussion (geht nahtlos über in die) <br />
* 16:15 Kaffeepause <br />
* 16:35 Vortrag mit Diskussion „Organisatorisches im Chapter“ <br />
* 17:15 Beginn der Beschlussfassungen und Wahlen <br />
* 17:25 Vortrag mit Diskussion „OWASP Germany Conference 2010“ <br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
===== Organisatorisches im Chapter =====<br />
<br />
Die Wesentlichen Punkte, die umgesetzt oder verbessert werden sollen: <br />
<br />
* Mehr Außenwirkung durch Public Relations, bessere Pressearbeit / Pressemitteilungen und Einführung und Pflege einer Sprecher- und Rednerliste (um z.B. bei öffentlichen Veranstaltungen OWASP adäquat vorstellen zu können) <br />
* Gepflegtes Wiki sowohl für Außendarstellung als auch als Plattform für die interne Kommunikation <br />
* Einführung von direkten Ansprechpartner für diverse Branchen<br />
<br />
Es folgt eine kurze Diskussion, wie dies effektiv umgesetzt werden kann. Es wird ein Vorschlag durch konkludentes Handeln angenommen: Es soll ein Chapter Board bestehend aus 5 Mitgliedern gewählt werden. Jedes dieser Mitglieder bekommt eine oder mehrere dedizierte Aufgabe(n), um die oben genannten Punkte abzudecken und umzusetzen. Es folgt ein Aufruf, sich für eine entsprechende Wahl zur Verfügung zu stellen. Es soll ebenso der neue Chapter Leader gewählt werden. Da sich nur ein Kandidat für nur einen Posten zur Wahl für die nächsten zwei Jahre zur Verfügung stellt, wird folgendes entschieden: Bei Abstimmungen hat jedes Mitglied des Boards genau eine Stimme, während der Chapter Leader zwei Stimmen hat. So soll zukünftig bei Abstimmungen eine Stimmengleichheit verhindert werden. <br />
<br />
===== Beschluss zur Anzahl der Chapter Leaders =====<br />
<br />
Es wird von den 12 Teilnehmern des Chapter Meetings einstimmig beschlossen, das zukünftig das Chapter Germany (analog zu den meisten anderen OWASP Chapters) nur noch einen Chapter Leader hat. <br />
<br />
===== Wahl des Chapter Leaders =====<br />
<br />
''Georg Heß'' kandidiert als Chapter Leader und wird mit 11 von 12 Stimmen bei einer Enthaltung zum neuen Chapter Leader des OWASP Chapters Germany gewählt. <br />
<br />
===== Beschluss zur zukünftigen Zusammensetzung des Boards =====<br />
<br />
Einstimmig wird beschlossen, dass das zukünftige Board aus 5 Mitgliedern besteht. Diese sollen die Aufgaben wie in der Diskussion beschrieben wahr nehmen. <br />
<br />
===== Wahl des Boards =====<br />
<br />
Es kandidieren ''Tobias Glemser, Boris Hemkemeier, Achim Hoffmann, Uli Petersen und Bruce Sams'' für die 5 Sitze im Board. Alle werden einstimmig gewählt. <br />
<br />
Alle Gewählten nehmen die Wahl an. <br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Not yet available in English, sorry.<br />
|}<br />
<br />
<br />
== OWASP German Chapter Meeting 10.07.2009, Mannheim ==<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
==== Einladaung ====<br />
;Summary:We will start with three interesting fresh talks. The following topics are the next activities of the OWASP German Chapter: the new [http://www.owasp.org/index.php/OWASP_German_Chapter_Stammtisch_Initiative "Stammtisch Initiative"] and the planning of the [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009] at Nuremberg. <br />
<br />
;Location:Aula of the [http://www.hs-mannheim.de Hochschule Mannheim], Building 3, Paul-Wittsack-Strasse 10, Mannheim ([http://maps.google.de/maps?f=d&source=s_d&saddr=Mannheim+Hbf&daddr=49.471303,8.48372&geocode=Fbr-8gIduTmBAA%3B&hl=de&mra=dme&mrcr=0&mrsp=1&sz=15&sll=49.474885,8.474715&sspn=0.015532,0.050254&ie=UTF8&z=15 Google Maps]). Please download the [http://www.hs-mannheim.de/campus/grafik/campusplan_legende_web.pdf campus map]. <br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Invitation ====<br />
<br />
|-<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Agenda ====<br />
* 12:00 - 13:00&nbsp;: Lunch (optional, please send an email to [mailto:Georg.Hess@artofdefence.com?subject=OWASP%20Chapter%20Meeting%20Lunch%20registration Georg Heß] to register for lunch), meeting point for the lunch is at the Aula in Building 3<br />
* 13:15 - 13:30 : Opening by our host Prof. Rainer Gerten (German) <br />
* 13:30 - 14:30 : OWASP Educational Services - Teaching Security!, Martin Knobloch, Member of OWASP Global Education Committee (English) <br />
* 14:30 - 15:00 : Vorstellung und aktueller Stand des OWASP Germany Projekts "Best Practice: Projektierung von Sicherheitsprüfungen von Web Applikationen", N.N., Projekt-Mitarbeiter (German) <br />
* 15:00 - 15:45 : Cloud Application Security - Chancen und Risiken - Einige Ansatzpunkte zum Thema, Georg Hess (German) <br />
* 15:45 - 16:15 : Coffee <br />
* 16:15 - 17:00 : Organisational topics of the OWASP German Chapter (German) <br />
** OWASP Stammtisch Initiative <br />
** Outlook and organisational tasks for the 2nd [[OWASP Germany 2009 Conference]]<br />
* nach 17:00 : Come together (Any ideas for a near pub??) <br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Agenda ====<br />
|-<br />
<br />
| style="vertical-align:top; padding-right:0.5em;" |<br />
==== Ergebnisse / Protokoll ====<br />
<br />
===== OWASP AppSec 2010 =====<br />
<br />
Es folgt ein kurzer historischer Rückblick der Veranstaltungsorte: 2008 im Hotel in Frankfurt, 2009 auf der Messe it-sa in Nürnberg. Kurze Diskussion pro und contra Hotel vs. Messe vs. Hochschul-Location. <br />
<br />
* Es soll geprüft werden, ob die diesjährige '''„OWASP Germany Conference 2010“''' wieder in Kooperation mit der Messe Nürnberg / it-sa durchgeführt werden kann (z.B. am 20.10.2010). <br />
* Weiterhin ist ein Konferenztag mit '''zwei verschiedenen Tracks (Technik und Management)''' angedacht. <br />
* Um die inhaltliche Gestaltung voranzutreiben wird ein '''Programm-Komitee''' (initial bestehend aus ''Bruce Sams, Kai Jendrian, Boris Hemkemeier und Martin Johns'') ins Leben gerufen, das alsbald den '''CFP''' starten soll.<br />
<br />
Gegen 18:15 löst sich das OWASP German Chapter Meeting auf und geht nahtlos in den 12. „Happy Anniversary!“ OWASP Stammtisch München über.<br />
<br />
Weitere Ergebnisse sind [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html in den Minutes hier] zu finden<br />
<br />
| style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
==== Protocol ====<br />
Minutes: [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html See the list archive for the minutes.]<br />
|}<br />
<br />
== OWASP German Chapter Meeting - February 20th, 2008 in Darmstadt ==<br />
<br />
;Date: February 20th, 2008, 11:00-16:15<br />
;Location: The next chapter meeting will be hosted at CAST in Darmstadt.<br />
: CAST (http://www.cast-forum.de)'''<br> Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt]<br />
<br />
;Agenda: This time the focus is on technical presentations and discussion.<br />
: Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion. <br />
# (11:00 - 11:15) Welcome, Introduction and Administrativia <br />
# (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann) <br />
# (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom) <br />
# (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Slides: [http://www.owasp.org/images/1/1b/WAF-Paper.pdf PDF]) (Alexander Meisel) <br />
# (12:30 - 13:15) Break <br />
# (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann) <br />
# (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss) <br />
: * "Input validation in ASP.NET -- tips, tricks &amp; pitfalls" (Boris Hemkemeier) <br />
: * "Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel) <br />
# (14:45 - 15:00) Coffee Break <br />
# (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias) <br />
# (15:45 - 16:00) Wrap-up and outlook<br />
<br />
== Chapter Meeting on September 7th 2007 in Frankfurt/Main ==<br />
<br />
After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00. <br />
<br />
This first chapter meeting had as its main goal the re-initiation of the German chapter and to start work on projects. Talks and presentations are secondary and will receive more focus at subsequent meetings. <br />
<br />
Read meeting notes/minutes [https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html here].<br />
<br />
<br />
----<br />
[[Germany|<top>]]<br />
<br />
[[Category:Germany]] [[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=145905User:Kai Jendrian2013-02-26T07:20:29Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai.jendrian@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 17 years of Network and Application operations and security<br />
* over 8 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee<br />
* Translation OWASP Top 10 German</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=145904User:Kai Jendrian2013-02-26T07:20:17Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai.jendrian@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 15 years of Network and Application operations and security<br />
* over 8 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee<br />
* Translation OWASP Top 10 German</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Stammtisch_Karlsruhe&diff=140641OWASP Stammtisch Karlsruhe2012-12-04T12:16:43Z<p>Kai Jendrian: </p>
<hr />
<div><br />
=== Karlsruhe ===<br />
<br />
===== 6. Pizza-Essen für die Sicherheit am 13.12.2012 =====<br />
<br />
Fast genau zum Jahrestag des letzten Karlsruher OWASP-Stammtisch treffen wir uns am 13.12.2012 um 19:30 Uhr in der [http://www.pizzeria-karlsruhe.de Pizzeria DaBenito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen. Wir können einen kurzen Rückblick auf die letzten Konferenzen geben und einen Ausblick auf anstehende Aktivitäten in 2013. Vielleicht mag ja jemand fachlichen Input mitbringen - immer her damit!<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=131021Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-06T09:23:29Z<p>Kai Jendrian: /* G 5.WA13 Cross-Site Scripting (XSS) (Ralf) */</p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (([[User:Kai Jendrian|Kai]])) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
Bei der Erwähnung von SSL oder TLS sollte eine einheitliche Schreibweise verwendet werden. Vorzugsweise SSL/TLS.<br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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, Cheat-Sheets).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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, Javascript, etc.? Was ist mit WebSockets?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
([[User:Kai Jendrian|Kai]]) B 5.XX Beschreibung<br />
<br />
Seite 1: Die vorgestellten '''Sicherheitskomponenten''' sind eher '''Sicherheitsmechanismen'''<br />
<br />
Seite 1: Es sollte heißen: vor dem Zugriff auf geschützte Ressourcen und '''Funktionen'''<br />
<br />
Seite 1: Ausgabedaten sollte nicht nur gefiltert sondern auch vor allem transformiert werden (output encoding)<br />
<br />
Seite 2: Wo genau werden AJAX-Anwendungen einsortiert, die auch XML oder JSON austauschen?<br />
<br />
Seite 2: Was ist die Botschaft des Satzes: "Aufgrund der Offenheit einer Web-Service..." - unklar!<br />
<br />
Seite 3: Beschaffung: Was ist mit Framerworks etc. (siehe [http://www.secorvo.de/security-news/secorvo-ssn1205.pdf Editorial der SSN 05/2012])?<br />
<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt. ([[User:Kai Jendrian|Kai]]) Und das noch auf verschiedenen Ebenen - hierzu zählt natürlich auch Anwendungslogik, die beispielsweise als API in einer Datenbank zur Verfügung gestellt wird.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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!=Individualsoftware)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
Allgemein ist der obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf.sinnvoll zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist unzureichender Schutz an dieser Stelle eine Gefährdung? Ist die Gefährdung nicht eher der Missbrauch<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich würde hier auch einen Verweis auf stärkere Authentifzierungsmechanismen erwarten - besonders SSL/TLS Client-Zertifiakte.<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist hier Korrelation gemeint?<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Zustimmung: Insbesondere weil bei der Nutzung von typsicher parametrisierten Datenbankanfragen (Stored Procedures) eine Validierung entfallen kann.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
([[User:Kai Jendrian|Kai]]) Nein - bei mir auch.<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
([[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.<br />
Mir scheint die einzige Quelle für '''reflexives XSS''' die deutsche Wikipedia zu sein - die in meinen Augen an dieser Stelle schlicht falsch übersetzt.<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
([[User:Kai Jendrian|Kai]])<br />
* Datenfluss<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstil! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
([[User:Kai Jendrian|Kai]]) Es sollte deutlich werden, dass Validierung von Daten häufig über die reine Prüfung mit Mechanismen wie Regulären Ausdrücken nicht erschlagen werden kann sondern deutlich komplexere Mechanismen erfordert.<br />
<br />
== M 4.WA06 Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07 Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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/Tar Pit, etc.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08 Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich finde die verallgemeinerte Prämisse schon falsch. Es sollte aber klar gestellt werden, ob und in welchem Maße automatische Zugriffe erlaubt und erwartet sind.<br />
<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11 Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist ([[User:Kai Jendrian|Kai]]) und was genau das bedeutet<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Hier könnte man auf die BNetzA verweisen [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html Übersicht der BNetzA]<br />
<br />
== M 4.WA13 Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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 "sicherheitsunbedenklichen Fehlermeldungen" oder so gesprochen werden.<br />
<br />
([[User:Kai Jendrian|Kai]]) Fehlermeldungen sollten sich angemessen an den jeweiligen Adressaten wenden: Userbezogen im Browser, Detailliert für Admins im Log, ggf. über einen Identifier korreliert.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15 Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
([[User:Kai Jendrian|Kai]]) s.o. Verweis auf BNetzA<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
<br />
([[User:Kai Jendrian|Kai]]) Siehe [https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html Baustein 1.7 Kryptokonzept]<br />
<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allerdings neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16 Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant ist<br />
<br />
([[User:Kai Jendrian|Kai]]) Der Verzicht auf aktive Inhalte ist definitiv nicht zeitgemäß. Siehe auch [https://www.owasp.org/images/a/ab/08_OWASP_German_Day_4_Invited_Talk_Von_Webseiten_zu_verteilten_Cloud-Anwendungen_-_Thomas_Roessler.pdf Closing Note OWASP Day 2011]. Es ist vielmehr eine Herausforderung, wie angemessen mit den aktiven Inhalten umgegangen werden kann. Einige Punkte: Vertrauenswürdigkeit von Quellen, Versionierung, ...<br />
<br />
== M 4.WA22 Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Die Rolle von Anfälligkeit gegen Angriffe wie Slowloris sollte berücksichtigt werden.<br />
<br />
== M 4.WA25 Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21 Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23 Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.<br />
<br />
([[User:Kai Jendrian|Kai]]) Mit Virtualisierung an sich beschäftigt sich ein eigener Baustein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=131020Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-06T08:48:45Z<p>Kai Jendrian: /* M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) */</p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (([[User:Kai Jendrian|Kai]])) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
Bei der Erwähnung von SSL oder TLS sollte eine einheitliche Schreibweise verwendet werden. Vorzugsweise SSL/TLS.<br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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, Cheat-Sheets).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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, Javascript, etc.? Was ist mit WebSockets?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
([[User:Kai Jendrian|Kai]]) B 5.XX Beschreibung<br />
<br />
Seite 1: Die vorgestellten '''Sicherheitskomponenten''' sind eher '''Sicherheitsmechanismen'''<br />
<br />
Seite 1: Es sollte heißen: vor dem Zugriff auf geschützte Ressourcen und '''Funktionen'''<br />
<br />
Seite 1: Ausgabedaten sollte nicht nur gefiltert sondern auch vor allem transformiert werden (output encoding)<br />
<br />
Seite 2: Wo genau werden AJAX-Anwendungen einsortiert, die auch XML oder JSON austauschen?<br />
<br />
Seite 2: Was ist die Botschaft des Satzes: "Aufgrund der Offenheit einer Web-Service..." - unklar!<br />
<br />
Seite 3: Beschaffung: Was ist mit Framerworks etc. (siehe [http://www.secorvo.de/security-news/secorvo-ssn1205.pdf Editorial der SSN 05/2012])?<br />
<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt. ([[User:Kai Jendrian|Kai]]) Und das noch auf verschiedenen Ebenen - hierzu zählt natürlich auch Anwendungslogik, die beispielsweise als API in einer Datenbank zur Verfügung gestellt wird.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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!=Individualsoftware)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
Allgemein ist der obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf.sinnvoll zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist unzureichender Schutz an dieser Stelle eine Gefährdung? Ist die Gefährdung nicht eher der Missbrauch<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich würde hier auch einen Verweis auf stärkere Authentifzierungsmechanismen erwarten - besonders SSL/TLS Client-Zertifiakte.<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist hier Korrelation gemeint?<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Zustimmung: Insbesondere weil bei der Nutzung von typsicher parametrisierten Datenbankanfragen (Stored Procedures) eine Validierung entfallen kann.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
([[User:Kai Jendrian|Kai]]) Nein - bei mir auch.<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
([[User:Kai Jendrian|Kai]])<br />
* Datenfluss<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstil! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
([[User:Kai Jendrian|Kai]]) Es sollte deutlich werden, dass Validierung von Daten häufig über die reine Prüfung mit Mechanismen wie Regulären Ausdrücken nicht erschlagen werden kann sondern deutlich komplexere Mechanismen erfordert.<br />
<br />
== M 4.WA06 Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07 Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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/Tar Pit, etc.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08 Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich finde die verallgemeinerte Prämisse schon falsch. Es sollte aber klar gestellt werden, ob und in welchem Maße automatische Zugriffe erlaubt und erwartet sind.<br />
<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11 Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist ([[User:Kai Jendrian|Kai]]) und was genau das bedeutet<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Hier könnte man auf die BNetzA verweisen [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html Übersicht der BNetzA]<br />
<br />
== M 4.WA13 Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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 "sicherheitsunbedenklichen Fehlermeldungen" oder so gesprochen werden.<br />
<br />
([[User:Kai Jendrian|Kai]]) Fehlermeldungen sollten sich angemessen an den jeweiligen Adressaten wenden: Userbezogen im Browser, Detailliert für Admins im Log, ggf. über einen Identifier korreliert.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15 Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
([[User:Kai Jendrian|Kai]]) s.o. Verweis auf BNetzA<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
<br />
([[User:Kai Jendrian|Kai]]) Siehe [https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html Baustein 1.7 Kryptokonzept]<br />
<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allerdings neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16 Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant ist<br />
<br />
([[User:Kai Jendrian|Kai]]) Der Verzicht auf aktive Inhalte ist definitiv nicht zeitgemäß. Siehe auch [https://www.owasp.org/images/a/ab/08_OWASP_German_Day_4_Invited_Talk_Von_Webseiten_zu_verteilten_Cloud-Anwendungen_-_Thomas_Roessler.pdf Closing Note OWASP Day 2011]. Es ist vielmehr eine Herausforderung, wie angemessen mit den aktiven Inhalten umgegangen werden kann. Einige Punkte: Vertrauenswürdigkeit von Quellen, Versionierung, ...<br />
<br />
== M 4.WA22 Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Die Rolle von Anfälligkeit gegen Angriffe wie Slowloris sollte berücksichtigt werden.<br />
<br />
== M 4.WA25 Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21 Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23 Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.<br />
<br />
([[User:Kai Jendrian|Kai]]) Mit Virtualisierung an sich beschäftigt sich ein eigener Baustein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=131019Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-06T08:45:24Z<p>Kai Jendrian: /* M 2.WA24 Web-Tracking (Matthias) */</p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (([[User:Kai Jendrian|Kai]])) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
Bei der Erwähnung von SSL oder TLS sollte eine einheitliche Schreibweise verwendet werden. Vorzugsweise SSL/TLS.<br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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, Cheat-Sheets).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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, Javascript, etc.? Was ist mit WebSockets?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
([[User:Kai Jendrian|Kai]]) B 5.XX Beschreibung<br />
<br />
Seite 1: Die vorgestellten '''Sicherheitskomponenten''' sind eher '''Sicherheitsmechanismen'''<br />
<br />
Seite 1: Es sollte heißen: vor dem Zugriff auf geschützte Ressourcen und '''Funktionen'''<br />
<br />
Seite 1: Ausgabedaten sollte nicht nur gefiltert sondern auch vor allem transformiert werden (output encoding)<br />
<br />
Seite 2: Wo genau werden AJAX-Anwendungen einsortiert, die auch XML oder JSON austauschen?<br />
<br />
Seite 2: Was ist die Botschaft des Satzes: "Aufgrund der Offenheit einer Web-Service..." - unklar!<br />
<br />
Seite 3: Beschaffung: Was ist mit Framerworks etc. (siehe [http://www.secorvo.de/security-news/secorvo-ssn1205.pdf Editorial der SSN 05/2012])?<br />
<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt. ([[User:Kai Jendrian|Kai]]) Und das noch auf verschiedenen Ebenen - hierzu zählt natürlich auch Anwendungslogik, die beispielsweise als API in einer Datenbank zur Verfügung gestellt wird.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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!=Individualsoftware)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
Allgemein ist der obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf.sinnvoll zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist unzureichender Schutz an dieser Stelle eine Gefährdung? Ist die Gefährdung nicht eher der Missbrauch<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich würde hier auch einen Verweis auf stärkere Authentifzierungsmechanismen erwarten - besonders SSL/TLS Client-Zertifiakte.<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist hier Korrelation gemeint?<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Zustimmung: Insbesondere weil bei der Nutzung von typsicher parametrisierten Datenbankanfragen (Stored Procedures) eine Validierung entfallen kann.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
([[User:Kai Jendrian|Kai]]) Nein - bei mir auch.<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
([[User:Kai Jendrian|Kai]])<br />
* Datenfluss<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstil! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
([[User:Kai Jendrian|Kai]]) Es sollte deutlich werden, dass Validierung von Daten häufig über die reine Prüfung mit Mechanismen wie Regulären Ausdrücken nicht erschlagen werden kann sondern deutlich komplexere Mechanismen erfordert.<br />
<br />
== M 4.WA06 Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07 Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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/Tar Pit, etc.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08 Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich finde die verallgemeinerte Prämisse schon falsch. Es sollte aber klar gestellt werden, ob und in welchem Maße automatische Zugriffe erlaubt und erwartet sind.<br />
<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11 Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist ([[User:Kai Jendrian|Kai]]) und was genau das bedeutet<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Hier könnte man auf die BNetzA verweisen [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html Übersicht der BNetzA]<br />
<br />
== M 4.WA13 Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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 "sicherheitsunbedenklichen Fehlermeldungen" oder so gesprochen werden.<br />
<br />
([[User:Kai Jendrian|Kai]]) Fehlermeldungen sollten sich angemessen an den jeweiligen Adressaten wenden: Userbezogen im Browser, Detailliert für Admins im Log, ggf. über einen Identifier korreliert.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15 Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
([[User:Kai Jendrian|Kai]]) s.o. Verweis auf BNetzA<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
<br />
([[User:Kai Jendrian|Kai]]) Siehe [https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html Baustein 1.7 Kryptokonzept]<br />
<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allerdings neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16 Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant ist<br />
<br />
([[User:Kai Jendrian|Kai]]) Der Verzicht auf aktive Inhalte ist definitiv nicht zeitgemäß. Siehe auch [https://www.owasp.org/images/a/ab/08_OWASP_German_Day_4_Invited_Talk_Von_Webseiten_zu_verteilten_Cloud-Anwendungen_-_Thomas_Roessler.pdf Closing Note OWASP Day 2011]. Es ist vielmehr eine Herausforderung, wie angemessen mit den aktiven Inhalten umgegangen werden kann. Einige Punkte: Vertrauenswürdigkeit von Quellen, Versionierung, ...<br />
<br />
== M 4.WA22 Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Die Rolle von Anfälligkeit gegen Angriffe wie Slowloris sollte berücksichtigt werden.<br />
<br />
== M 4.WA25 Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21 Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23 Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.<br />
<br />
([[User:Kai Jendrian|Kai]]) Mit Virtualisierung an sich beschäftigt sich ein eigener Baustein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=131018OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-06T08:37:09Z<p>Kai Jendrian: /* Project Contributors */</p>
<hr />
<div>[[Category:OWASP_Project|OWASP Review BSI IT-Grundschutz Baustein Webanwendungen]]<br />
==Mailing-List, Coordination and Contact==<br />
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 :-)<br />
<br />
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]]<br />
<br />
This is a project of the [[Germany | OWASP German Chapter]].<br />
<br />
==Abstract==<br />
Technical review of the module web application<br />
("Baustein Webanwendungen") of the IT-baseline protection catalog ("IT<br />
Grundschutz Katalog") of the German Federal Office for Information<br />
Security ("BSI") from the OWASP's point of view.<br />
<br />
==Introduction==<br />
The German "Federal Office for Information Security" (BSI), which is<br />
comparable to departments focused on security in organizations like NIST<br />
or CCTA, offers the IT Baseline Protection ("IT-Grundschutz") for public<br />
usage, which is based on ISO/IEC 27001. The IT Baseline Protection<br />
include a catalog of approx. 80 "Bausteine" (building blocks). Those<br />
blocks are dealing with one particular subject of IT security. They are<br />
usually written in the German language and later translated to English.<br />
They become the de facto standard for IT security and related<br />
certifications in Germany after they are finally released.<br />
<br />
In January 2012 the draft of the block "Webanwendungen" (web<br />
applications) was released with a request for comments. Since this is<br />
the core expertise of OWASP we invited a delegate of the BSI to attend<br />
the last chapter meeting of the German Chapter which took place in<br />
Frankfurt / Main on the 3rd of February. The meeting's outcome was the<br />
strong wish to perform a review of that very web application block as an<br />
OWASP project. This project will help to expand the visibility of OWASP<br />
in the German IT security landscape broadly.<br />
<br />
<br />
==Roadmap==<br />
* Time is running out, so it's just: <b>Review!</b><br />
* Details [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]]<br />
<!--<br />
* Building a coordinating team<br />
* <b>Defining the review rules</b> [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| see "Discussion"]] <br />
* Reading the BSI documents<br />
* Collecting comments from the community familiar with the BSI documents<br />
* Creating a common understanding<br />
* Writing a review with OWASP glasses <br />
* Review of OWASP's review itself<br />
* Releasing the result(s)<br />
--><br />
<br />
==Deadline==<br />
06/01/2012, in German: '''01.06.2012'''<br />
<br />
<br />
==Relevant links and general information==<br />
==== Document download ====<br />
"Entwurf Baustein Webanwendungen" of the BSI (in German language) directly: <br />
[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]<br />
<br />
General download section of the BSI:<br />
[https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/download/download.html https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/download/download.html]<br />
<br />
==== Some further information about "BSI" and "Grundschutz"====<br />
The BSI about itself: [https://www.bsi.bund.de/EN/Home/home_node.html https://www.bsi.bund.de/EN/Home/home_node.html ]<br />
<br />
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]<br />
<br />
Wikipedia about "IT-Grundschutz Katalog": [http://en.wikipedia.org/wiki/IT_Baseline_Protection_Catalogs http://en.wikipedia.org/wiki/IT_Baseline_Protection_Catalogs]<br />
<br />
<br />
==Actual Work in Progress==<br />
<br />
===Allgemeine Punkte===<br />
<br />
<span style="text-decoration: underline">[[OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen/Allgemeine_Punkte|Allgemeine Punkte]]</span>.<br />
<br />
===Kapitel-Review===<br />
<br />
Hier eine <u>Auflistung der einzelnen Kapitel / Teile / Review-TODOs</u> - wer einen Teil übernehmen möchte schreibt sich bitte einfach ein (im Feld <u>Person</u>).<br />
<br />
Im <u>Kommentarfeld</u> 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"). <br />
<br />
Unter <u>Status</u> könnt Ihr das folgende angeben:<br />
* <b>offen</b> (dieser Teil ist noch unbearbeitet)<br />
* <b>in Arbeit</b> (dieser Teil wird aktuell bearbeitet)<br />
* <b>in Diskussion</b> (Arbeit des initialen Reviewers abgeschlossen; Kommentierung / peer review durch andere wird durchgeführt)<br />
* <b>geschlossen</b> (die Kommentierung dieses Teils ist abgeschlossen)<br />
* <b>übernommen</b> (dieser Teil wurde in das finale Word-Dokument übernommen)<br />
<br />
{| class="wikitable"<br />
|-<br />
! Kapitel / Teil<br />
! Person<br />
! Status<br />
! Kommentar<br />
|-<br />
| B 5.XX Web-Anwendungen, Beschreibung und Abgrenzung<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
<!--| G 2.1 Fehlende oder unzureichende Regelungen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- <br />
| G 2.4 Unzureichende Kontrolle der Sicherheitsmaßnahmen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.7 Unerlaubte Ausübung von Rechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.22 Fehlende Auswertung von Protokolldaten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.27 Fehlende oder unzureichende Dokumentation<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.67 Ungeeignete Verwaltung von Zugangs- und Zugriffsrechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.87 Verwendung unsicherer Protokolle in öffentlichen Netzen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 2.103 Unzureichende Schulung der Mitarbeiter<br />
| Matthias<br />
| offen<br />
| keiner<br />
|- --><br />
| G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
<!-- | G 3.16 Fehlerhafte Administration von Zugangs- und Zugriffsrechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 3.38 Konfigurations- und Bedienungsfehler<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 3.43 Ungeeigneter Umgang mit Passwörtern<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 4.22 Software-Schwachstellen oder -Fehler<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- --><br />
| G 4.33 Unzureichende oder fehlende Authentisierung<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
<!-- | G 4.35 Unsichere kryptographische Algorithmen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- --><br />
| G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen<br />
| Tobias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen<br />
| Matthias<br />
| in Diskussion<br />
| keiner<br />
|-<br />
<!-- | G 5.18 Systematisches Ausprobieren von Passwörtern<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 5.19 Missbrauch von Benutzerrechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 5.20 Missbrauch von Administratorrechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 5.28 Verhinderung von Diensten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| G 5.87 Web-Spoofing<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- --><br />
| G 5.131 SQL-Injection<br />
| Ralf<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA10 Fehler in der Logik von Web-Anwendungen<br />
| Ralf<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen<br />
| Ralf<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA12 Unzureichendes Session-Management von Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA13 Cross-Site Scripting (XSS)<br />
| Ralf<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF)<br />
| Matthias<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA17 Injection-Angriffe<br />
| Ralf<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| G 5.WA18 Clickjacking<br />
| Matthias<br />
| in Diskussion<br />
| Markus<br />
|-<br />
<!--| M 2.1 (A) Festlegung von Verantwortlichkeiten und Regelungen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.31 (C) Dokumentation der zugelassenen Benutzer und Rechteprofile<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.34 (A) Dokumentation der Veränderungen an einem bestehenden System<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.63 (A) Einrichten der Zugriffsrechte<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.64 (A) Kontrolle der Protokolldateien<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.110 (B) Datenschutzaspekte bei der Protokollierung<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 5.66 (Z) Verwendung von TLS/SSL<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- --><br />
| M 2.WA02 (B) Dokumentation der Architektur von Web-Anwendungen<br />
| Matthias<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA20 (A) Sicherer Entwurf der Logik von Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 2.WA12 (B) Entwicklung und Erweiterung von Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 5.WA21 (A) Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 5.WA23 (A) Systemarchitektur einer Web-Anwendung<br />
| Makrus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 2.WA24 (W) Web-Tracking<br />
| Matthias<br />
| in Diskussion<br />
| keiner<br />
|-<br />
<!-- | M 4.176 (A) Auswahl einer Authentisierungsmethode für Webangebote<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.80 (A) Erstellung eines Anforderungskatalogs für Standardsoftware<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.62 (A) Software-Abnahme- und Freigabe-Verfahren<br />
| Matthias<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.363 (A) Schutz gegen SQL-Injection<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 3.5 (B) Schulung zu Sicherheitsmaßnahmen<br />
| Matthias<br />
| offen<br />
| keiner<br />
|- --><br />
| M 4.WA04 (A) Authentisierung bei Web-Anwendungen<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA05 (A) Umfassende Ein- und Ausgabevalidierung bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA06 (A) Session-Management bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA07 (A) Fehlerbehandlung durch Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA08 (B) Schutz vor automatisierter Nutzung von Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA11 (A) Sichere Konfiguration von Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA13 (A) Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA15 (A) Schutz vertraulicher Daten bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA16 (A) Zugriffskontrolle bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA19 (B) Verhinderung von Cross-Site Request Forgery (CSRF, XSRF)<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA22 (B) Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen<br />
| Markus<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA25 (C) Verhinderung von Clickjacking<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
<!-- | M 2.8 (A) Vergabe von Zugriffsrechten<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.35 (A) Informationsbeschaffung über Sicherheitslücken des Systems<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 2.273 (A) Zeitnahes Einspielen sicherheitsrelevanter Patches und Updates<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|-<br />
| M 4.78 (B) Sorgfältige Durchführung von Konfigurationsänderungen<br />
| unbekannt<br />
| offen<br />
| keiner<br />
|- --><br />
| M 4.WA09 (C) Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| M 4.WA14 (A) Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen<br />
| Markus<br />
| in Diskussion<br />
| keiner<br />
|-<br />
| Dokument "Webanwendungen_Goldene Regeln.pdf"<br />
| Matthias<br />
| In Diskussion<br />
| keiner<br />
|-<br />
| Dokument "Webanwendungen_Hilfsmittel.pdf"<br />
| Markus<br />
| <b>in Diskussion</b><br />
| keiner<br />
|-<br />
| Dokument "Webanwendungen_Kreuzreferenztabelle.pdf"<br />
| unbekannt<br />
| <b>offen</b><br />
| keiner<br />
|-<br />
|}<br />
Weitere Informationen und die aktuellen Arbeitsstände gibt es unter [[Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen| "Discussion"]].<br />
<br />
==Coordinating Team==<br />
* Tobias Glemser<br />
* Boris Hemkemeier<br />
* Kai Jendrian<br />
* Ralf Reinhardt<br />
* Dirk Wetter<br />
<br />
==Project Contributors==<br />
* Dennis Moers<br />
* Markus Miedaner<br />
* [[User:Mrohr|Matthias Rohr]]<br />
* [[User:Kai Jendrian|Kai Jendrian]]<br />
* ''Your name here''<br />
<br />
==Project Licence==<br />
Creative Commons Attribution ShareAlike 3.0</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=131017Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-06T06:48:45Z<p>Kai Jendrian: </p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (([[User:Kai Jendrian|Kai]])) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
Bei der Erwähnung von SSL oder TLS sollte eine einheitliche Schreibweise verwendet werden. Vorzugsweise SSL/TLS.<br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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, Cheat-Sheets).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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, Javascript, etc.? Was ist mit WebSockets?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
([[User:Kai Jendrian|Kai]]) B 5.XX Beschreibung<br />
<br />
Seite 1: Die vorgestellten '''Sicherheitskomponenten''' sind eher '''Sicherheitsmechanismen'''<br />
<br />
Seite 1: Es sollte heißen: vor dem Zugriff auf geschützte Ressourcen und '''Funktionen'''<br />
<br />
Seite 1: Ausgabedaten sollte nicht nur gefiltert sondern auch vor allem transformiert werden (output encoding)<br />
<br />
Seite 2: Wo genau werden AJAX-Anwendungen einsortiert, die auch XML oder JSON austauschen?<br />
<br />
Seite 2: Was ist die Botschaft des Satzes: "Aufgrund der Offenheit einer Web-Service..." - unklar!<br />
<br />
Seite 3: Beschaffung: Was ist mit Framerworks etc. (siehe [http://www.secorvo.de/security-news/secorvo-ssn1205.pdf Editorial der SSN 05/2012])?<br />
<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt. ([[User:Kai Jendrian|Kai]]) Und das noch auf verschiedenen Ebenen - hierzu zählt natürlich auch Anwendungslogik, die beispielsweise als API in einer Datenbank zur Verfügung gestellt wird.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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!=Individualsoftware)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
Allgemein ist der obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf.sinnvoll zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist unzureichender Schutz an dieser Stelle eine Gefährdung? Ist die Gefährdung nicht eher der Missbrauch<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich würde hier auch einen Verweis auf stärkere Authentifzierungsmechanismen erwarten - besonders SSL/TLS Client-Zertifiakte.<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist hier Korrelation gemeint?<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Zustimmung: Insbesondere weil bei der Nutzung von typsicher parametrisierten Datenbankanfragen (Stored Procedures) eine Validierung entfallen kann.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
([[User:Kai Jendrian|Kai]]) Nein - bei mir auch.<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
([[User:Kai Jendrian|Kai]])<br />
* Datenfluss<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstil! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
([[User:Kai Jendrian|Kai]]) Es sollte deutlich werden, dass Validierung von Daten häufig über die reine Prüfung mit Mechanismen wie Regulären Ausdrücken nicht erschlagen werden kann sondern deutlich komplexere Mechanismen erfordert.<br />
<br />
== M 4.WA06 Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07 Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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/Tar Pit, etc.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08 Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich finde die verallgemeinerte Prämisse schon falsch. Es sollte aber klar gestellt werden, ob und in welchem Maße automatische Zugriffe erlaubt und erwartet sind.<br />
<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11 Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist ([[User:Kai Jendrian|Kai]]) und was genau das bedeutet<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Hier könnte man auf die BNetzA verweisen [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html Übersicht der BNetzA]<br />
<br />
== M 4.WA13 Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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 "sicherheitsunbedenklichen Fehlermeldungen" oder so gesprochen werden.<br />
<br />
([[User:Kai Jendrian|Kai]]) Fehlermeldungen sollten sich angemessen an den jeweiligen Adressaten wenden: Userbezogen im Browser, Detailliert für Admins im Log, ggf. über einen Identifier korreliert.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15 Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
([[User:Kai Jendrian|Kai]]) s.o. Verweis auf BNetzA<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
<br />
([[User:Kai Jendrian|Kai]]) Siehe [https://www.bsi.bund.de/ContentBSI/grundschutz/kataloge/baust/b01/b01007.html Baustein 1.7 Kryptokonzept]<br />
<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allerdings neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16 Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant ist<br />
<br />
([[User:Kai Jendrian|Kai]]) Der Verzicht auf aktive Inhalte ist definitiv nicht zeitgemäß. Siehe auch [https://www.owasp.org/images/a/ab/08_OWASP_German_Day_4_Invited_Talk_Von_Webseiten_zu_verteilten_Cloud-Anwendungen_-_Thomas_Roessler.pdf Closing Note OWASP Day 2011]. Es ist vielmehr eine Herausforderung, wie angemessen mit den aktiven Inhalten umgegangen werden kann. Einige Punkte: Vertrauenswürdigkeit von Quellen, Versionierung, ...<br />
<br />
== M 4.WA22 Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Die Rolle von Anfälligkeit gegen Angriffe wie Slowloris sollte berücksichtigt werden.<br />
<br />
== M 4.WA25 Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21 Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23 Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.<br />
<br />
([[User:Kai Jendrian|Kai]]) Mit Virtualisierung an sich beschäftigt sich ein eigener Baustein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=130970Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-05T14:56:25Z<p>Kai Jendrian: </p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (([[User:Kai Jendrian|Kai]])) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
Bei der Erwähnung von SSL oder TLS sollte eine einheitliche Schreibweise verwendet werden. Vorzugsweise SSL/TLS.<br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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, Cheat-Sheets).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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, Javascript, etc.? Was ist mit WebSockets?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
([[User:Kai Jendrian|Kai]]) B 5.XX Beschreibung<br />
<br />
Seite 1: Die vorgestellten '''Sicherheitskomponenten''' sind eher '''Sicherheitsmechanismen'''<br />
<br />
Seite 1: Es sollte heißen: vor dem Zugriff auf geschützte Ressourcen und '''Funktionen'''<br />
<br />
Seite 1: Ausgabedaten sollte nicht nur gefiltert sondern auch vor allem transformiert werden (output encoding)<br />
<br />
Seite 2: Wo genau werden AJAX-Anwendungen einsortiert, die auch XML oder JSON austauschen?<br />
<br />
Seite 2: Was ist die Botschaft des Satzes: "Aufgrund der Offenheit einer Web-Service..." - unklar!<br />
<br />
Seite 3: Beschaffung: Was ist mit Framerworks etc. (siehe [http://www.secorvo.de/security-news/secorvo-ssn1205.pdf Editorial der SSN 05/2012])?<br />
<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt. ([[User:Kai Jendrian|Kai]]) Und das noch auf verschiedenen Ebenen - hierzu zählt natürlich auch Anwendungslogik, die beispielsweise als API in einer Datenbank zur Verfügung gestellt wird.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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!=Individualsoftware)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
Allgemein ist der obere Teil ok, die aufgezählten "Auswirkungen von fehlenden Vorgaben" verstehe ich jedoch nicht. Wo ist etwa der Bezug von Barrierefreiheit auf die Anwendungssicherheit?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf.sinnvoll zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist unzureichender Schutz an dieser Stelle eine Gefährdung? Ist die Gefährdung nicht eher der Missbrauch<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich würde hier auch einen Verweis auf stärkere Authentifzierungsmechanismen erwarten - besonders SSL/TLS Client-Zertifiakte.<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
([[User:Kai Jendrian|Kai]]) Ist hier Korrelation gemeint?<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
([[User:Kai Jendrian|Kai]]) Zustimmung: Insbesondere weil bei der Nutzung von typsicher parametrisierten Datenbankanfragen (Stored Procedures) eine Validierung entfallen kann.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09 Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
([[User:Kai Jendrian|Kai]]) Nein - bei mir auch.<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15 Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16 Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
([[User:Kai Jendrian|Kai]])<br />
* Datenfluss<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstil! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
([[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.<br />
<br />
== M 4.WA05 Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
([[User:Kai Jendrian|Kai]]) Es sollte deutlich werden, dass Validierung von Daten häufig über die reine Prüfung mit Mechanismen wie Regulären Ausdrücken nicht erschlagen werden kann sondern deutlich komplexere Mechanismen erfordert.<br />
<br />
== M 4.WA06 Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07 Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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/Tar Pit, etc.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08 Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
<br />
([[User:Kai Jendrian|Kai]]) Ich finde die verallgemeinerte Prämisse schon falsch. Es sollte aber klar gestellt werden, ob und in welchem Maße automatische Zugriffe erlaubt und erwartet sind.<br />
<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09 Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11 Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist ([[User:Kai Jendrian|Kai]]) und was genau das bedeutet<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Hier könnte man auf die BNetzA verweisen [http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html Übersicht der BNetzA]<br />
<br />
== M 4.WA13 Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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 "sicherheitsunbedenklichen Fehlermeldungen" oder so gesprochen werden.<br />
<br />
([[User:Kai Jendrian|Kai]]) Fehlermeldungen sollten sich angemessen an den jeweiligen Adressaten wenden: Userbezogen im Browser, Detailliert für Admins im Log, ggf. über einen Identifier korreliert.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15 Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
([[User:Kai Jendrian|Kai]]) s.o. Verweis auf BNetzA<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allerdings neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16 Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant ist<br />
<br />
([[User:Kai Jendrian|Kai]]) Der Verzicht auf aktive Inhalte ist definitiv nicht zeitgemäß. Siehe auch [https://www.owasp.org/images/a/ab/08_OWASP_German_Day_4_Invited_Talk_Von_Webseiten_zu_verteilten_Cloud-Anwendungen_-_Thomas_Roessler.pdf Closing Note OWASP Day 2011]. Es ist vielmehr eine Herausforderung, wie angemessen mit den aktiven Inhalten umgegangen werden kann. Einige Punkte: Vertrauenswürdigkeit von Quellen, Versionierung, ...<br />
<br />
== M 4.WA22 Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]) Die Rolle von Anfälligkeit gegen Angriffe wie Slowloris sollte berücksichtigt werden.<br />
<br />
== M 4.WA25 Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21 Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23 Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.<br />
<br />
([[User:Kai Jendrian|Kai]]) Mit Virtualisierung an sich beschäftigt sich ein eigener Baustein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=130969Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-06-05T13:56:21Z<p>Kai Jendrian: </p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (.kai) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.<br />
<br />
== Rechtschreibung und Formulierungen (Dirk, Ralf, Kai) ==<br />
<br />
''Web-Anwendung'' kann man so schreiben, klingt aber für ein IT-Werk altbacken. <br />
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.<br />
<br />
Nur tauchen auch ''Webserver'' oder ''Webseiten'' in den Katalogen und auch in diesem Baustein auf. Eins geht nur.<br />
<br />
'''Empfehlung:''' Besonders in diesem Baustein nur noch die Schreibweise ''Webanwendung'' verwenden. Ggf. gesamte Katalogen vorsichtig<br />
per Suchen und Ersetzen dies sprachlich gerade ziehen<br />
<br />
Weiterhin:<br />
"JavaScript" (CamelCase) sollte überall konsistent verwendet werden; nicht zwischendrin "Javascript" nutzen.<br />
<br />
Allgemein spricht die Mehrheit der deutschsprachigen Community (vgl. z.B. OWASP Top Ten oder Google-Suchtreffer) von "reflektiertem XSS", nicht "revlexives XSS". <br />
Es sollte überall "reflektiertes XSS" statt "reflexives XSS" genutzt werden, <br />
<br />
=== Verbindlichkeit ===<br />
<br />
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. <br />
<br />
== "Hilfsmittel" (Markus, Matthias) ==<br />
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.<br />
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. <br />
<br />
([[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.<br />
<br />
SQL-Injection Characters:<br />
die Pipe fehlt hier zur Textkonatenierung<br />
+ / - haben auch eine Bedeutung bei JOINs.<br />
<br />
([[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!<br />
<br />
([[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).<br />
<br />
== "Goldene Regeln" (Matthias, Kai) ==<br />
<br />
Hier meine Anmerkungen zu diesem Dokument:<br />
<br />
; 1. Fehlende Punkte:<br />
* Korrektur der Ursache (Root Cause) von Schwachstellen statt Verhinderung deren Ausnutzung<br />
* Bezug auf Minimierung der Angriffsfläche und Least-Privilege-Prinzip<br />
* Bezug auf Defense-in-Depth-Prinzip<br />
* Verwendung von getesteten Security APIs (z.B. OWASP ESAPI, Kryptografischer Schutz) statt selbstentwickelter Funktionen<br />
* Bezug auf Externalisierung von Sicherheitsfunktionen, sowie deklarative vor programmatischer Sicherheit.<br />
* Verallgemeinerung von Prinzipien statt zu konkreter Beispiele in den ''goldenen Regeln''<br />
<br />
; 2. Begriff "Web-Anwendung"<br />
Würde ich generell durch "Webanwendung" ersetzen (s.o.).<br />
<br />
; 3. Einleitung ("Web-Anwendungen stellen Funktionalität zur Verfügung, ...")<br />
<br />
Wozu dient dieser Satz?<br />
Ist die Einleitung wirklich notwendig - und wenn ja, warum ist sie dann nicht ausführlicher.<br />
<br />
; 4. "Die Architektur der Web-Anwendung ist im Sicherheitskonzept zu dokumentieren....." <br />
<br />
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.<br />
<br />
; 5. "Bei Web-Anwendungen handelt es sich häufig um spezielle Eigenentwicklungen...."<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Die Gliederung von OpenSAMM könnte als sinnvolle Orientierung dienen.<br />
<br />
; 6. "Alle Ein- und Ausgaben der Web-Anwendung müssen in eine normalisierte Form überführt werden...."<br />
<br />
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.<br />
<br />
Zweitens, finde ich den weiteren Text zwar grundsätzlich formal korrekt, aber so allgemein, dass dieser glaube ich niemandem so richtig etwas bringt. <br />
<br />
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.<br />
<br />
Eingabedaten können technisch zudem auch Werte eingelesener Property-Dateien sein. Muss ich die auch validieren? Ist das dann noch Grundschutz? <br />
<br />
([[User:Kai Jendrian|Kai]]): Alle Daten aus nicht-vertrauenswürdigen Quellen sind zu prüfen. Hierzu kann bpsw. auch Local-Storage gehören. Die Vertrauenswürdigkeit sollte sich aus der Dokumentation von Vertrauensgrenzen ergeben.<br />
<br />
; 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. ...."<br />
<br />
Besser fände ich "eine Authentisierung, die über eine dem Schutzbedarf der Anwendung angemessene Stärke verfügt." <br />
<br />
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. <br />
<br />
Zudem fehlt hier meiner Meinung nach der Hinweis auf die bevorzugte Verwendung getesteter Standardkomponenten.<br />
<br />
([[User:Kai Jendrian|Kai]]): Es sollte deutlich werden, dass eine '''Session''' nur eine Krücke ist, um eine erfolgreiche Authentisierung und Authentifizierung über ein zustandsloses Protokoll (HTTP) zu erhalten.<br />
<br />
; 8. "Die Web-Anwendung sollte die zu übermittelnden Daten schützen."<br />
<br />
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.<br />
<br />
; 9. "Die Preisgabe interner Informationen (z.B. Kommentare, Fehlermeldungen)"<br />
<br />
Hier würde ich eher schreiben "(In Kommentaren, Fehlermeldungen, HTTP Headern, etc.)"<br />
<br />
; 10. "Fehler müssen so behandelt werden, ... müssen Fehler bei der Autorisierung zu einer Verweigerung beim Zugriff auf die angeforderte Ressource führen."<br />
<br />
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)."<br />
<br />
; 11. "Die Logging-Funktionen der Web-Anwendung müssen aufgetretene Ereignisse derart protokollieren, dass sicherheitskritische Vorfälle nachvollzogen werden können."<br />
<br />
Hier würde hier eher von "allen sicherheitsrelevanten Ereignissen" sprechen.<br />
<br />
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.<br />
<br />
([[User:Kai Jendrian|Kai]]): Oder es muss durch die Art der Protokollierung sichergestellt sein, dass ausschließlich ein datenschutzkonformer Zugriff auf die Log-Informationen möglich ist.<br />
<br />
; 12. "Alle Sicherheitsmechanismen (z.B. Authentisierung und Zugriffskontrolle) sind serverseitig zu implementieren und können nicht durch clientseitige Mechanismen ersetzt werden."<br />
<br />
Die Aussage ist so nicht korrekt. Darüber hatten wir bereits bei der ASVS mehrfach diskutiert. <br />
<br />
Ü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.<br />
<br />
== "Gefährdungen" (Markus, Dennis, .... <Dein Name>) ==<br />
; Generell:<br />
Reference auf RFCs fehlen.<br />
<br />
==B.5.XX Web-Anwendungen ==<br />
; 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?<br />
; 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 . . . <br />
; 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.<br />
; 4.Vorsätzliche Handlungen -> Web-Spoofing (G.5.87) -- Missverständliche Bezeichnung / Nomenklatur<br />
; 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.<br />
; 6 Seite 5: "Umsetzung" - Wir haben CSRF, D(D)os und SQL-Injection aber wo ist XSS?<br />
; 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.<br />
; 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.<br />
; 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.<br />
<br />
<br />
tbd.<br />
<br />
; Wortwahl:<br />
Ich stosse innerhalb der Texte immer wieder an die Worten '''Hintergrundsystem''' und '''Sicherheitskontext'''.<br />
'''Hintergrundsystem:''' besseres Synonym?<br />
'''Sicherheitskontext:''' nur weil es in den Texten um Sicherheit geht muss nicht an jeder Stelle immer wieder das Wort _Sicherheits_kontext eingebaut werden.<br />
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)<br />
Verbesserungsansansatz: ... so kann er die Web-Anwendung anstelle des eigentlichen Besitzers weiterhin verwenden.<br />
<br />
== "G 2.WA01 Mangelhafte Auswahl oder Konzeption von Web-Anwendungen" (Matthias) ==<br />
<br />
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. <br />
<br />
Na gut, ich konzentriere mich mal auf die fachlichen Punkte:<br />
<br />
; 1. Security Controls<br />
Werden mal mit "Schutzmechanismen", mal mit "Sicherheitskomponenten" und dann wieder als "Sicherheitsfunktionen" bezeichnet. Hier macht eine einheitliche Benennung sicherlich Sinn und ist weniger verwirrend.<br />
<br />
; 2. "Eine Web-Anwendung ist in der Regel ein verteiltes, komplexes System bestehend aus unterschiedlichen Komponenten (z. B. Webserver, Applikationsserver, Hintergrundsysteme)"<br />
<br />
Eine Webanwendung besteht sicher nicht aus einem Webserver- oder anderer infrastruktureller Komponenten, sondern ist Software welches diese nutzt.<br />
<br />
; 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"<br />
<br />
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.<br />
<br />
; 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."<br />
<br />
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).<br />
<br />
Wichtiger wäre in diesem Zusammenhang zudem die fehlende Berücksichtigung bestimmter Security Controls.<br />
<br />
; 5. "Auswahl von Web-Anwendungen auf Basis von Standardsoftware"<br />
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)? <br />
<br />
; 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."<br />
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).<br />
<br />
; 7. "Die Hintergrundsysteme werden unzureichend abgesichert und dadurch ist die Datenbank der Web-Anwendung aus dem Internet erreichbar."<br />
Gehören fehlende Netzwerksegmentierung bzw. Firewallregeln wirklich in diesen Kontext? Das ist doch eigentlich Grundschutz der Infrastruktur, oder?<br />
<br />
; 8. "Aufgrund schwacher Parameter in der Konfiguration des Frameworks zum Session-Management werden unsichere SessionIDs erzeugt."<br />
Was sind "schwache" Parameter?<br />
<br />
Welches Framework erlaubt unsichere SessionIDs durch eine "schwache" Konfiguration zu erzeugen?<br />
<br />
; 9. "Wird die Konfiguration des Web-Browsers durch einen Angreifer manipuliert, können die clientseitig umgesetzten"<br />
<br />
Manipuliert ein Angreifer die Konfguration seines Webbroswers, wenn er einen MITM-Proxy konfiguriert?<br />
<br />
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).<br />
<br />
<br />
== "G 5.WA10 Fehler in der Web-Anwendungslogik" (Dennis, Matthias) ==<br />
; 1. "Damit kann aufgrund der Prüfreihenfolge ein hoher Ressourcenverbrauch provoziert werden, der für Denial-of-Service-Angriffe ausgenutzt werden kann."<br />
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.<br />
<br />
([[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.<br />
<br />
== "G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen" (Dennis) ==<br />
; 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)."<br />
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.<br />
<br />
<br />
== G 2.WA02 Mängel bei der Entwicklung und der Erweiterung von Web-Anwendungen (Matthias) ==<br />
<br />
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?<br />
<br />
Mein Vorschlag, um diese Punkte etwa sinnvoll umzubauen:<br />
* "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<br />
* "Fehlende Programmierrichtlinien" => Besser wäre hier "Fehlende Sicherheitsrichtlinien in der Programmierung" also "Secure Coding Guidelines"<br />
* "Testfälle" => "Sicherheitsrelevante Testfälle" (z.B. Security Unit Tests). <br />
* "Barrierefreiheit": Warum nicht an dieser Stelle die Auswirkungen von Sicherheitsfunktionen auf die Bedienbarkeit, etwa anhand von CAPTCHAS erläutern?<br />
<br />
== G 2.WA03 Unzureichender Schutz personenbezogener Daten bei Web-Anwendungen (Matthias) ==<br />
<br />
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. <br />
<br />
Die Punkt 1-3 sollten daher besser entfallen und z.B. durch die Folgenden ersetzt werden:<br />
* Unsichere Einbindung von sozialen Netzwerken (Bezug nehmen auf den Like-Button bei Facebook)<br />
* Unsichere Einbindung von Werbeinhalten<br />
* Unsichere Übertragung und Caching<br />
* Unsichere Protokollierung<br />
* Ungenügender Zugriffsschutz<br />
* Verstoß des Minimalprinzips bzw. der Zweckgebundenheit (welche Daten werden wirklich benötigt)<br />
<br />
Auch wäre es ggf. zumindest einen Verweis auf das BDSG zu machen.<br />
<br />
== G 4.33 Unzureichende oder fehlende Authentisierung (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Wenn Authentisierungsmechanismen fehlen oder zu schlecht sind"<br />
<br />
"schlecht" sollte vlt besser durch "unzureichend" ersetzt werden.<br />
<br />
; 2. "Sicherheitslücken entstehen bei... der Benutzerauthentisierung"<br />
<br />
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<br />
<br />
; 3. "Sicherheitslücken entstehen bei... der Komponentenauthentisierung"<br />
<br />
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.<br />
<br />
; 4. "Sicherheitslücken entstehen bei... der Wahl des Verfahrens"<br />
<br />
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.<br />
<br />
; 5. Serverseitige Authentisierung fehlt<br />
<br />
Auch der Server (bzw. die Anwendung selbst) kann sich fehlerhaft oder ungenügend beim Benutzer authentsieren, etwa über DNS, SSL-Zertifikate, etc.<br />
<br />
== G 4.WA04 Unzureichende Validierung von Ein- und Ausgabedaten bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. "Unzureichende Validierung von Eingabedaten"<br />
<br />
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.<br />
<br />
; 2. "Unzureichende Validierung von Ausgabedaten"<br />
<br />
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).<br />
<br />
; 3. "Die Suchfunktion der Web-Anwendung verwendet die Eingaben der Benutzer ungefiltert"<br />
<br />
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.<br />
<br />
; 4. "Ungefilterter HTML-Code in Kommentar-Funktion"<br />
<br />
Hier fehlt der Bezug auf persistentes XSS, das hier sicherlich zentral ist.<br />
<br />
== G 4.WA05 Fehlende oder mangelhafte Fehlerbehandlung durch Web-Anwendungen (Tobias, Matthias) ==<br />
; Abschnitt "Unsichere Fehlerbehandlung"<br />
Die G adressiert "Unsichere Fehlerbehandlung", der Abschnitt die "Unsichere Fehlerbehandlung in Sicherheitskomponenten". Entsprechend sollte der fettgedruckte Teil angepasst werden.<br />
<br />
; "fehlende SQL-Parameter,"<br />
Sollte besser "Fehlermeldungen bei ungültigen SQL-Abfragen" lauten.<br />
<br />
; "Auch scheinbar unkritische Informationen, wie die Meldung ob (..)"<br />
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."<br />
<br />
<br />
([[User:Mrohr|Matthias]]): Stimme dem Obigen auch zu, ausserdem:<br />
<br />
; ([[User:Mrohr|Matthias]]): Sprachlich: "kann dies unvorhersehbare Auswirkungen haben und den Betrieb der Web-Anwendung bis zur Unerreichbarkeit einschränken."<br />
<br />
"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.<br />
<br />
; ([[User:Mrohr|Matthias]]): "Clientseitige Fehlerbehandlung"<br />
Das stimmt soweit, das generelle Problem ist jedoch genereller, naehmlich die clientseitige Abbildung sicherheitsrelaventer Logik (in diesem Fall die Fehlerbehandlung)<br />
<br />
== G 4.WA06 Unzureichende Nachvollziehbarkeit von sicherheitsrelevanten Ereignissen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Erster Absatz: "Die Behebung einer Schwachstelle ist dann nicht oder nur unter erschwerten Bedingungen möglich."<br />
<br />
Hier würde ich ergänzen: "...und Angriffe auf die Anwendungen können ggf. nicht erkannt oder nachvollzogen werden".<br />
<br />
; 2. "Beispiele": Kommulierbarkeit<br />
<br />
Hier fehlt auch ein Bezug auf die Kommulierbarkeit von SIcherheitsereignissen, dass diese also auch von solchen anderer Systeme in Verbindung gesetzt werden können<br />
<br />
; 3. "Beispiele": Gerichtsverwertbarkeit<br />
<br />
Auch die Möglichkeit zur Gerichtsverwertbarkeit (etwa durch eindeutigen Zeitstempel) und manipulationssicherer Speicherung, würde ich an dieser Stelle unbedingt erwähnen.<br />
<br />
== G 4.WA07 Offenlegung von Informationen bei Web-Anwendungen (Matthias) ==<br />
<br />
; 1. Titel<br />
<br />
Hier würde ggf. "Offenlegung vertraulicher Informationen" sicher besser passen als "Offenlegung von Informationen".<br />
<br />
; 2. Beispiellink<br />
<br />
Ein Beispiellink (mit und ohne Token) würde sicher die Verständlichkeit dieser Schwachstelle verbessern.<br />
<br />
; 3. Erster Absatz: "Wenn demzufolge Informationen unnötig offengelegt werden, steigt die Wahrscheinlichkeit eines erfolgreichen Angriffs."<br />
<br />
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.<br />
<br />
; 4. Fehlende Punkte<br />
<br />
* Ein Hinweis auf HTTP Header wäre hier sicher erwähnenswert.<br />
* Weiterhin bzgl. der Anzeige von Traces und ein Verweis auf den Entsprechenden Baustein zur Fehlerbehandlung<br />
<br />
== G 5.131 SQL-Injection (Ralf) ==<br />
; Erster Absatz, Zeile 4<br />
ist mir zu eingeschränkt. Mein Vorschlag: <br />
"zusätzliche SQL-Anweisungen" ersetzten durch "geänderte oder zusätzliche SQL-Anweisungen"<br />
<br />
; Erster Absatz, letzter Satz:<br />
Bei Regen wird die Straße "möglicherweise" nass. Man sollte imho den Konjunktiv diskutieren oder die genaue Definition von "Sicherheitsmechanismus".<br />
Ist das Design der ursprünglichen Query an sich schon ein Sicherheitsmechanismus, oder die ursprüngliche Einschränkung auf einen geeigneten Primärschlüssel? <br />
Welche "Mechanismen" können denn trotz SQLI noch "möglicherweise" greifen? Eine "WAF"? Ist das ein Mechanismus der Anwendung selbst oder nur vorgelagert? Kann es in einer Anwendung überhaupt mechanische Teile für einen Mechanismus geben? Ich breche das jetzt mal ab... ;-)<br />
<br />
;Auflistung, zweiter Spiegelstrich:<br />
"Manipulation von Daten," klingt für mich zu harmlos. Ich würde expliziter auf CRUD eingehen:<br />
"Erzeugen, Auslesen, Verändern oder Löschen von Daten,"<br />
<br />
;Auflistung, letzter Spiegelstrich:<br />
"Zugriff auf weitere Server."<br />
Geht es hier um einzelne Requests (wie z.B. ein HTTP-Get oder eine DNS-Abfrage), dann bin ich dabei. Geht es um mehr, so ist das aber imho nur eine indirekte Folge z.B. durch die Installation einer Shell auf der DB-Maschine, die dann weiterführend genutzt werden kann (ja, wir sind immer noch *nur* bei SQLI).<br />
<br />
; Vorletzter Absatz:<br />
"wird dabei durch eine unzureichende Validierung [...] ermöglicht" ist eben nur die halbe Wahrheit. Der Kern einer (jeden) Injection liegt in der dynamischen Query:<br />
Unvalidierter Input des Benutzers wird direkt genutzt, um ihn an eine dynamischen Query/Abfrage/Kommando-String zu kleben, der dann in dieser manipulierten Form auf einen Interpreter / Parser trifft. Ich schlage vor: "wird dabei durch [...] ermöglicht ([...]), die in dieser Form direkt in eine dynamische Query eingebaut werden." Vielleicht sollte man aber den ganzen Satz umbauen, und mit dem Problem der dynamisch konkatenierten Abfrage beginnen.<br />
<br />
== G 5.WA08 Unberechtigter Zugriff auf oder Manipulation von Daten bei Web-Anwendungen (Markus) ==<br />
; 1. Generell sollte der Zugriff auf LogFiles stark eingeschränkt werden.<br />
; 2. Der zu protokollierende Inhalt sollte wohl überlegt sein, dass ein Troubleshooting möglich ist, aber persönliche / zu schützende Daten nicht protokolliert werden.<br />
; 3. Cookies: Die muss man nicht umbedingt auslesen, man kann sie einfach wieder verwenden - dieser Punkt wird nicht in Erwägung gezogen. Warum sollte ich mir die Mühe machen, etwas zu entziffern, was ich in einer Spoofing / Replay-Attacke verwenden kann?<br />
<br />
== G 5.WA09Missbrauch einer Web-Anwendung durch automatisierte Nutzung (Markus) ==<br />
; 1. Hier findet keine Unterscheidung zwischen einer automatischen Nutzung der GUI (Client) und REST bzw. SOAP Schnittstellen statt. Für mich (persönlich) liegt der Fokus auf der GUI. Hier wünsche ich mir ein paar Sätze zum automat. Missbrauch von Schnittstellen.<br />
<br />
== G 5.WA10 Fehler in der Logik von Web-Anwendungen (Ralf) ==<br />
; Letztes Beispiel, Kurzbezeichnung rechts<br />
Kann ich nicht lesen "ÄndrXXXX", hier ist das Layout zerschossen. Ist das nur bei meinem Reader so?<br />
<br />
== G 5.WA11 Umgehung clientseitig umgesetzter Sicherheitsfunktionen von Web-Anwendungen (Ralf) ==<br />
; Generelle Überlegung zu Clients<br />
Die Seite des Clients gehört immer vollständig dem Angreifer, am Ende des Tages geht ein Request an die Anwendung, und dieser Request ist erst mal "Evil Input".<br />
Clientseitige Validierung ist manchmal nett, um Last vom Server zu nehmen (und natürlich muss min. die gleiche Validierung nochmal komplett serverseitig statt finden!). <br />
Aber wie sieht's mit Request-Headern aus, z.B. wenn sich die Anwendung an einer Stelle auf den User-Agent verlässt? Ist das nur "dämlich programmiert" oder ist das schon eine "clientseitige Sicherheitsfunktion"? Gesetzte Parameter auf Client-Seite, die mehr oder weniger statisch und nicht mit der Serverseite "verschränkt" sind, sollten imho nie in den Stand einer "Sicherheitsfunktion" gehoben werden, das kann nur daneben gehen (verschränkt wäre in meiner Sprechweise z.B. eine Anti-CSRF-Token, wenn es pro Request unique, geheim, zeitlich und im use case beschränkt ist).<br />
<br />
== G 5.WA12Unzureichendes Session-Management von Web-Anwendungen (Markus) ==<br />
; 1. Den letzten Satz des ersten Absatzes würde ich umformulieren. Der Angreifer muss sich nicht identifizieren. Er kann die Anwendung als ein anderer User bedienen. Credentials sind nicht so wichtig hier. Warum bäuchte man einen Schlüssel, wenn das Tor zum Schloss offen steht?<br />
; 2. Der Autor erwähnt nicht, dass eine SessionID, sobald sie nicht mit dem Login - bzw. zu bestimmten Zeitpunkten geändert wird einfach wieder verwendet werden kann. Das "Erraten" von SessionIds ist in diesem Zusammenhang etwas anderes.<br />
<br />
== G 5.WA13 Cross-Site Scripting (XSS) (Ralf) ==<br />
Die Schreibweise für JS ist inkonsistent: "Javascript" vs. "JavaScript". Ich bin klar für CamelCase.<br />
<br />
Weiterhin bevorzuge ich die Schreibweise "reflektiertes XSS" anstelle von "reflexives XSS". Letzteres ist imho eine schlechte Übertragung aus dem Englischen.<br />
In Quotes gesucht hat die Schreibweise "reflektiert" auch 20 Mal mehr Treffer. Und, last but not least: In den Top Ten steht auch "reflektiert" :-)<br />
<br />
; Erstes Beispiel, persistentes XSS, Mitte:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers."<br />
Ist nicht vollständig korrekt. Es muss heißen:<br />
"[...] und hat somit Zugriff auf die clientseitig im Cookie gespeicherte SessionID des Benutzers, wenn dieses Session-Cookie (fehlerhaft) ohne HttpOnly-Flag gesetzt wurde."<br />
<br />
== G 5.WA14 Cross-Site Request Forgery (CSRF, XSRF) (Matthias) ==<br />
<br />
; 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"<br />
<br />
Statt "Funktionen" würde ich besser von "schreibenden Aktionen" sprechen, dann macht der Satz mehr Sinn.<br />
<br />
; 2. Dritter Absatz: "Im Gegensatz zu XSS (siehe ... ) ist das Angriffsziel nicht die Information auf dem Client (z. B. in Cookies),"<br />
<br />
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."<br />
<br />
; 3. Session Riding<br />
<br />
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.<br />
<br />
Im Grunde ist Session Riding aber nur ein Synonym für CSRF. Der Absatz ist daher auch nur eine Wiederholung der obigen Beschreibung.<br />
<br />
; 4. Zum Beispiel: "Durch einen präparierten Link auf einer Webseite wird die Änderung des Zugangspasswortes des Routers eingeleitet."<br />
<br />
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."<br />
<br />
== G 5.WA15Umgehung der Autorisierung bei Web-Anwendungen (Markus) ==<br />
; 1. NullBytes - Das OS ignoriert nicht das NullByte. Das können wir so nicht stehen lassen.<br />
; 2. Warum eine Datei runterladen, wenn ich sie auch überschreiben kann? Das fehlt mir hier :)<br />
; 2. Forced Browsing, so alt es auch sein mag, man findet es immer wieder.<br />
; Meiner Meinung nach sind Beispiel ungeschickt gewählt. Umgehung von Authorisierungskomponenten hat auch direkt eine Verbindung zum Sessionmanagement - davon findet man aber nichts in diesem Absatz.<br />
<br />
<br />
<br />
== G 5.WA16Einbindung von fremden Daten und Schadcode bei Web-Anwendungen (Markus) ==<br />
; 1. Sprachlich fallen die letzten beiden Sätze des ersten Absatz unangenehm auf. Das sollten wir umformulieren, damit es sich leichter liest: Bsp.: zu erkennen und der Angreifer kann die Vertrauensstellung des Nutzers....<br />
; 2. Einbinden von Schadecode - Hier fehlt mir die Referenz zu XSS/XSRF.<br />
; 3. Der Schadecode scheint sich immer nur gegen den User zu richten - was ist mit DDOS über injizierten SchadeCode?<br />
; 4. Der mögliche Missbrauch der Rechenressourcen des Nutzers (Browser-Rootkits, etc.) wird nicht erwähnt.<br />
; 5. Missbrauch der Uploadfunktion -> Ok, man die Systeme aber auch einfach so lange mit nutzlosen Daten füllen, bis sie nicht mehr nutzbar sind - DOS. Der Punkt fehlt hier.<br />
; 5 Uploadfunktionen -> Malicious Scripts -> gezielter Missbrauch der verletzbaren Server, um andere Systeme auszuschalten, zu brechen. Das wird ebenfalls verschwiegen.<br />
<br />
== G 5.WA17 Injection-Angriffe (Ralf) ==<br />
; Grundsätzliches Vorgehen <br />
ersetze "Interpreter" mit "Parser oder Interpreter"<br />
<br />
== G 5.WA18 Clickjacking (Matthias) ==<br />
<br />
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.<br />
(Markus) - Das Beispiel ist nicht gut gewählt. Ein PayPerClick ist zu harmlos. SANS verwendet eine FlashApp mit Screenshot und Soundaufzeichnung. Das verdeutlicht die Dimension besser.<br />
<br />
== M 2.WA02 Dokumentation der Architektur von Web-Anwendungen (Matthias) ==<br />
<br />
; Verantwortlich für die Umsetzung<br />
Hier wäre auch die Nennung des "Architekten" sinnvoll<br />
<br />
; Fehlende Bestandteile der Dokumentation:<br />
* Schutzbedarf des Systems sowie der verarbeiteten Daten<br />
* Schützenswerte Daten und Funktionen (Assets)<br />
* Betriebliche Anforderungen an die Sicherheit bzw. eingesetzte Plattform<br />
* Dokumentierte Konfigurationseinstellungen <br />
* BIA (RTO, RPO)<br />
* Schnittstellen<br />
* Trust Boundaries<br />
* Akteure (bzw. Trust Level)<br />
* Sicherheitsannahmen<br />
* Geltende Compliance-Anforderungen (BDSG, PCI DSS, etc.)<br />
<br />
; Benutzermanagement<br />
<br />
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. <br />
<br />
; Prüffragen<br />
<br />
Hier fehlt etwas in Bezug auf Sicherheitsanforderungen. Beispiel: "Werden Sicherheitsanforderungen an den Betrieb während der Entwicklung abgestimmt und dokumentiert"<br />
<br />
== M 2.WA12 Entwicklung und Erweiterung von Anwendungen (Markus) ==<br />
; "Es sollte darauf geachtet werden, dass Sicherheitsanforderungen<br />
vollständig durch Sicherheitsmechanismen erfüllt und zur Erstellung von<br />
Testfällen festgehalten werden." --> Bessere Formulierung würde aussagen, dass die Sicherheitsanforderungen durch Testfälle verifiziert werden.<br />
"(z. B. durch Kommentare im<br />
Quelltext). Somit ist der Quelltext zu einem" --> Das ist kein empfehlenswerter Programmierstiel! Raus mit diesem Kommentar<br />
;"Zum Schutz vor dem Verlust bereits entwickelter und verworfener<br />
Lösungen sowie zu Dokumentationszwecken sollte die Historie der<br />
Änderungen festgehalten werden (z. B. durch ein Revisionssystem)." --> Auch diesen Absatz können wir streichen - Kein professioneller Programmierer arbeitet ohne Versionierugssystem.<br />
;"Bei Web-Anwendung sollten die Webseiten auf Konformität zu dem<br />
verwendeten Standard (z. B. HTML-Standard) getestet werden. Dadurch<br />
können unvorgesehene Seiteneffekte aufgrund einer Fehlinterpretation<br />
seitens der Browser vermieden werden." --> Könnte man noch um "Die Software ist in möglichst vielen Browsern zu testen" erweitern.<br />
;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.<br />
;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.<br />
; "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.<br />
; "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!!!<br />
<br />
<br />
== M 2.WA24 Web-Tracking (Matthias) ==<br />
<br />
; Letzter Absatz: "Falls eine Auswertung von Nutzerdaten, insbesondere personenbezogener Daten, .. "<br />
<br />
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.<br />
<br />
== M 4.WA04 Authentisierung bei Web- Anwendungen (Matthias) ==<br />
<br />
: Verantwortlich fuer Umsetzung <br />
sollte in erster Linie beim Architekturen und in zweiter beim Entwickler liegen<br />
; Vermischung von Authentisierung und Session Management <br />
<br />
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.<br />
<br />
; Verwendung von Frameworks<br />
<br />
Die Anforderung ist schon ein wenig eingeschränkt. Besser passt hier denke ich die "Abbildung der Authentisierung über Standardkomponenten (Bibliotheken oder Frameworks)". <br />
<br />
; Remember-Me-Funktion<br />
<br />
Siehe oben, gehört zum Session Management. Das ließt sich im übrigen so, als ob eine Webanwendung Credentials auf dem Client abhängt. <br />
<br />
; Grenzwerte für gescheiterte Anmeldeversuche<br />
<br />
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). <br />
<br />
Etwa umsetzbar durch<br />
* Sperrung nach x Anmeldeversuchen<br />
* Throttling<br />
* Captchas<br />
* Sicherheitsfragen<br />
<br />
Das allgemeine Sperren kann leicht für das gezielte Aussperren von Benutzern (User Lockout) verwendet werden. Was etwa bei Trading-Anwendungen nicht funktioniert.<br />
<br />
; Automatisiertes Zurücksetzen von Authentisierungsdaten<br />
<br />
Würde ich besser als "Passwort-Reset" bezeichnen.<br />
<br />
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.<br />
<br />
; Registrierung nicht behandelt<br />
<br />
Es existiert hier kein Punkt, der die sichere Implementierung von Benutzerregistrierungen behandelt.<br />
<br />
; Verweis auf Externalisierung fehlt.<br />
<br />
Statt die Authentisierung selbst durchzuführen kann eine Anwendung hierzu auf eine externe Komponente (Beispiel: SiteMinder oder Kerberos) zurückgreifen.<br />
<br />
; Verweis auf Behandlung von Credentials fehlt<br />
<br />
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.<br />
<br />
== M 4.WA05Umfassende Ein- und Ausgabevalidierung bei Web-Anwedungen (Markus) ==<br />
; "Ablehnung der Daten im<br />
Fehlerfall" --> Hier könnte man noch auf Tar-Pits eingehen - nur ein Vorschlag.<br />
<br />
== M 4.WA06Session-Management bei Web-Anwendungen (Markus, Matthias) ==<br />
; "Ü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.<br />
<br />
([[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.<br />
<br />
; "Verschlüsselte Übertragung von SessionIDs" --> Hier fehlt der Hinweis auf den Beast-Exploit. TLS Version > 1.0 verwenden!<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Weiterhin:<br />
<br />
Es dürfen keine extern bekannten oder erratbaren Daten (z. B. IP-Adresse, Uhrzeit) in die Berechnung der SessionID einfließen.<br />
<br />
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.<br />
<br />
- Domain (z. B. webapp.domain.tld),<br />
- Path (z. B. /webapp/),<br />
- Secure und<br />
- HttpOnly.Beschränkte Sitzungsdauer<br />
<br />
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"?<br />
<br />
== M 4.WA07Fehlerbehandlung durch Web-Anwendungen (Markus, Matthias) ==<br />
; Konsistenter / Inkonsistener Zustand einer Webanwendung und der daraus resultierende Datenverlust: Hier fehlen mir die Punkte: DOS, Priv.Escalation, CodeExecution.<br />
([[User:Mrohr|Matthias]]) Vorschlag "und somit der Schutz der Daten" aendern in "und somit ETWA der Schutz der Daten" korrigieren<br />
<br />
; Vermeidung vertraulicher Informationen in Fehlermeldungen --> Fehlermeldungen sollten ebenfalls eine Systeminformationen preisgeben (Softwareversion, Patchlevel, etc.)<br />
([[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.<br />
<br />
; Abbruch des Vorgangs nach Auftreten eines Fehlers --> TarPits scheinen dem Autor umbekannt zu sein :)<br />
([[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.<br />
<br />
; "Werden Fehler möglichst von der gleichen Komponente behandelt, in der<br />
der Fehler aufgetreten ist?" --> Das "möglichst" sollten wir streichen.<br />
([[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.<br />
<br />
== M 4.WA08Schutz vor automatisierter Nutzung von Web-Anwendungen (Markus, Matthias) ==<br />
; "Brute-Force-<br />
Angriffe (z. B. Erraten von Zugangsdaten) und Enumeration-Angriffe (z. B.<br />
automatisiertes Ermitteln von gültigen Login-Namen)" -- die Beispiele sind identisch - besser Beispiele suchen, z.b. URL-Enumeration<br />
<br />
([[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.<br />
<br />
== M 4.WA09Protokollierung sicherheitsrelevanter Ereignisse von Web-Anwendungen (Markus) ==<br />
; 1. Zu protokollierende Merkmale: Abhängig von der Komponente sollte / könnte auch die SourceIP mit gelogged werden. Das ist bei DOS-Attacken hilfreich.<br />
; 2. Zu protokollierende Merkmale: Aufgetretene Fehler -> Hier sind das System (Rechner in einem Cluster / einer Kette) sowie der Softwarestand von entscheidender Bedeutung.<br />
; 3. "Erkannte Manipulationsversuche" - gute Idee, aber das ist doch eigentlich ein Fischen im trüben - meint der Autor damit Anomalien (Protokoll, Inhalt, Häufigkeit --> IDS?)<br />
; 4. Referenzen auf eine SessionId (nicht die SessionId selbst), auf einen User etc. sind sehr hilfreich, wenn es darum geht, das Verhalten eines Nutzers in einer hoch modularen Anwendung (innerhalb eines Clusters/Cloud) zu verfolgen - das fehlt hier.<br />
; 5. Logrotation und Verschlüsselung der LOGFiles werden nicht besprochen.a<br />
<br />
== M 4.WA11Sichere Konfiguration von Web-Anwendungen (Markus, Matthias) ==<br />
; "Sicherer Umgang mit TLS/SSL" -- Hier fehlt der Hinweis, dass TLS-1.0 gebrochen ist<br />
; "Zeichenkodierungskonfiguration" -- Ein Whitelisting abhängig von der Encodierung wäre ein weiterer Vorschlag<br />
; "Restriktive Dateisystemberechtigungen" -- auch wenn es ein klassiker ist - der AS sollte ebenfalls mit von einem eingeschränkten Nutzer gestartet werden und nicht als root<br />
; Administration Consolen:zur Ergänzen: Wenn diese nicht benötigit, sollten derartige Applikationen nicht deployed werden, unabhängig von möglichen Zugangsbeschränkungen.<br />
<br />
([[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.<br />
<br />
== M 4.WA13Kontrolliertes Einbinden von Daten und Inhalten bei Web-Anwendungen (Markus) ==<br />
; 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<br />
; Upload komprimierter Dateien / großer Dateien birgt die Gefahr von DOS Angriffen<br />
; Upload von Dateien kann bei weiterem Parsing zu Speicherengpässen führen --> DOS-Angriffe auf Thread-Local etc.<br />
<br />
<br />
== M 4.WA14Restriktive Herausgabe sicherheitsrelevanter Informationen bei Web-Anwendungen (Markus, Matthias) ==<br />
OK - Keine Anmerkungen von mir.<br />
<br />
([[User:Mrohr|Matthias]]) Von mir schon;)<br />
<br />
; ([[User:Mrohr|Matthias]]) Vermeidung von Kommentaren in ausgelieferten Webseiten<br />
<br />
Das ist leider total falsch, wir brauchen haeufig Komentare, aus Kompatibilitaetsgruenden. So wird etwa der JavaScript-Block haeufig auskommentiert.<br />
<br />
Wurde stattessen besser von sicherheitsrelevanten Kommentaren sprechen und als Massnahme generell Entwicklerkommentare ueber Sprachkonstruktre (etwa JSP) durchzufuehren.<br />
<br />
; ([[User:Mrohr|Matthias]]) Löschen nicht benötigter Dateien<br />
<br />
Hier wurde ich ggf. Dateien von Versionisierungstools (etwa Subversion) erwaehnen, das sehen wir schon recht haeufig.<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Gibt die Web-Anwendung ausschließlich neutrale Fehlermeldungen aus und sind diese im Quelltext identisch? {E: C}<br />
<br />
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.<br />
<br />
; ([[User:Mrohr|Matthias]]) Wird der Referrer bei Verlassen der Web-Anwendung (z. B. durch einen Link auf eine externe Seite) gefiltert?<br />
<br />
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.<br />
<br />
== M 4.WA15Schutz vertraulicher Daten bei Web-Anwendungen (Markus, Matthias) ==<br />
; Sichere kryptographische Algorithmen:<br />
Hier fehlt mir eine Liste der aktuelle als sicher geltenden Verfahren.<br />
([[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]<br />
<br />
; Schlüssel<br />
Das die Schlüssel bestimmten Formaten entsprechen müssen ist ok - aber das Schlüsselmanagement wird gar nicht besprochen?<br />
; Schutz der Daten im Browsercache<br />
Skripte und Browserplugins können ebenfalls auf den Browsercache zugreifen - diese werden hier nicht erwähnt.<br />
<br />
([[User:Mrohr|Matthias]]) Weiterhin entsprechen die vorgeschlagenen HTTP Headern nicht dem Best Practice:<br />
<br />
Cache-control: no-cache, no-store<br />
Pragma: no-cache<br />
Expires: -1<br />
<br />
([[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. <br />
<br />
; Maskierung von Passwörtern <br />
Dies schützt bei der Eingabe nur vor ShoulderSurfing nicht vor Skripten oder Plugins die diese an andere Server posten.<br />
<br />
([[User:Mrohr|Matthias]]) Das ist voellig korrekt. Aber inwieweit ist die Aussage Passwort-Felder zu verwenden fehlerhaft bzw. hier unzureichend beschrieben?<br />
<br />
; Sicherung von Zugangsdaten:<br />
Zugangsdaten in einer Datei abzulegen - wenn auch ausserhalb des WebRoots ist keine gute Idee.<br />
([[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.<br />
; Schutz von Quelltexten:<br />
Hier würde ich property files mit aufnehmen. der hinweis auf web-inf/classes fehlt - warum?<br />
Bei include-befehlen sind die pfadangaben zu überdenken.<br />
([[User:Mrohr|Matthias]]) Wuerde property Dateien allgemein den Konfigurationsdateien zuordnen. Der Begriff "Einzubindende Dateien" ist mir allrdings Neu<br />
<br />
([[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.<br />
<br />
; ([[User:Mrohr|Matthias]]) - Durch dieses Attribut wird die Gültigkeit des Cookies auf die Domäne der Web-Anwendung beschränkt.<br />
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.<br />
<br />
== M 4.WA16Zugriffskontrolle bei Web-Anwendungen (Markus) ==<br />
; Zugriffskontrolle via Frameworks:<br />
Dieser Punkt (Frameworks) wird nur in einem Satz erwähnt. Es werden keine Bespiele gegeben - Das ist zu wenig.<br />
Es müssen alle Zugriffe geschützt werden. Eine Protokollierung aller Zugriffe mit den nötigen Informationen ist ebenfalls empfehlenswert.<br />
; Datei Upload:<br />
Die Gefahr eines DOS wird hier nicht erwähnt.<br />
<br />
== M 4.WA19Verhinderung von Cross-Site Request Forgery (CSRF, XSRF) (Markus, Matthias) ==<br />
; Verantwortliche: <br />
Entwickler und Admins!<br />
([[User:Mrohr|Matthias]]) Korrekt, wobei auch in der Reihenfolge<br />
<br />
; Anti-CSRF-Token in hidden fields:<br />
Das ist keine gute Idee. Ich würde das streichen!<br />
<br />
([[User:Mrohr|Matthias]]) Watt? Anti-CSRF-Tokens in Hidden Fields sind die Standard-Massnahme. Wie denn sonst? Bitte nicht streichen!!! <br />
<br />
([[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.<br />
<br />
; Umgehung von Schutzmechanismen:<br />
Man in the middle hat keinen direkten Bezug zu CSRF! Das würde ich streichen.<br />
([[User:Mrohr|Matthias]]) Der Hinweis ist korrekt. Wovon der Autor hier spricht ist Session Replay nicht CSRF.<br />
<br />
; Frameworks:<br />
Gute Idee - aber es gibt auch Features in den ApplicationServern die CSRF unterbinden - warum wird das nicht besprochen?<br />
<br />
([[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.<br />
<br />
([[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.<br />
<br />
== M 4.WA20Sicherer Entwurf der Logik von Web-Anwendungen (Markus, Matthias) ==<br />
; Rollbacks:<br />
Tritt ein Fehler auf muss die Applikation einen konsistenten Datenstand zurück lassen. Das wird hier nicht erwähnt.<br />
; RaceConditions:<br />
Fehler in der Geschäftslogik können auch durch zwei gleichzeitige Sessions auf einer Webapplikation auftreten - das wird hier nicht besprochen.<br />
<br />
([[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.<br />
<br />
Nichts desto trotz, was hier als "echte" Massnahmen erwaehnt werden sollte sind:<br />
* Verhinderung von Race Conditions, aber nicht nur durch Concurrent Sessions sondern auch durch Singletons (TOCTOU)<br />
* Enforcements von Workflows, etwa durch die Verwendung von State Machines oder Request Tokens (auch bekannt als Site Usage Enforcement)<br />
* Fail Securely (bzw. Verweis)<br />
* Serverseitige Abbildung der Anwendungslogik, zumindest wenn diese sicherheitsrelevant sit<br />
<br />
== M 4.WA22Verhinderung der Blockade von Ressourcen (DoS) bei Web-Anwendungen (Markus, Matthias) ==<br />
; Datenspeicher:<br />
Neben dem Datenspeicher sollte auch der RAM-Verbrauch pro Thread der Applikation limitiert werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, ich wuerde hier sogar allgemein von Ressourcenverbrauch am Beispiel RAM und Datenspeicher, sprechen<br />
<br />
; Voraggregation von Daten / Caching<br />
Dieser Punkt fehlt: Stark ressourcen belastende Anfragen können auch in Lastarmen Zeiten vorberechnet werden.<br />
([[User:Mrohr|Matthias]]) Stimmt, koennte noch als Anmerkung bei "Cachen von Anfragen" hinzugefuegt werden<br />
<br />
; ([[User:Mrohr|Matthias]]) Prueffrage: "Wird ein möglicher Überlauf von Protokolldaten... verhindert"<br />
<br />
Ist eine etwas eingeschrankte Sicht. Wurde hier eher von Ueberlauf von Speicherplaz zu Beispiel im Rahmen der Protokollierung sprechen<br />
<br />
; ([[User:Mrohr|Matthias]]) Durchfuehrung von Lasttests zur Identifikation ressourcenintensiver Operationen<br />
<br />
Der Hinweis waere ggf. erwahnenswert<br />
<br />
; ([[User:Mrohr|Matthias]]) Hinweis auf nicht-angemeldeten Bereich<br />
<br />
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.<br />
<br />
== M 4.WA25Verhinderung von Clickjacking (Markus, Matthias) ==<br />
Ok - das passt soweit.<br />
<br />
([[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.<br />
<br />
== M 5.WA21Sichere Anbindung von Hintergrundsystemen an Web-Anwendungen (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Architekten fehlen. Entwickler müssen die Views umsetzen und die Datasource entsprechend einbinden - die fehlen hier ebenfalls.<br />
; DirectorySystem Beispiel:<br />
Das DirectorySystem wird in dem angegeben Beispiel zum Single Point of Failure - das wird verschwiegen.<br />
; Firewalls:<br />
Das sind fachlich-blinde Systeme. Was ist mit WAFs / IDS / IPS etc.?<br />
([[User:Mrohr|Matthias]]) Stimmt, das hat in diesem Baustein nichts zu suchen<br />
<br />
; ([[User:Mrohr|Matthias]]) Typische Hintergrundsysteme<br />
Hier fehlt irgendwie "Middleware", die ist denke ich nicht immer Legacy<br />
<br />
== M 5.WA23Systemarchitektur einer Web-Anwendung (Markus, Matthias) ==<br />
; Verantwortliche:<br />
Auch hier fehlend wieder die Architekten. <br />
([[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.<br />
<br />
; Virtualisierung:<br />
Virtualisierung bietet weitere Angriffsvektoren (z.B.: Hypervisor) die eine "Blech"Farm nicht bietet.<br />
<br />
([[User:Mrohr|Matthias]]) Genau, wobei auch der ganze Bereich geshareter Plattformen (z.B. By SharePoint) hier fehlt.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=126751Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-03-23T08:03:41Z<p>Kai Jendrian: </p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (.kai) ==<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Talk:OWASP_Review_BSI_IT-Grundschutz_Baustein_Webanwendungen&diff=126750Talk:OWASP Review BSI IT-Grundschutz Baustein Webanwendungen2012-03-23T08:03:10Z<p>Kai Jendrian: </p>
<hr />
<div>Since it's about a review of a document in German, all the discussions will be done in German :-)<br />
<br />
Diskussionen rund um den Review des "IT-Grundschutzbausteins Webanwendungen" finden hier statt, sinnvollerweise auf Deutsch :-)<br />
<br />
== Vorschlag für Kriterien, die an unser Review angelegt werden sollten (.kai)<br />
<br />
* Der Baustein soll alle wichtigen Themen der Entwicklung sicherer<br />
Webanwendungen enthalten.<br />
<br />
* Der Baustein soll die verschiedenen Phasen der Software-Entwicklung<br />
vollständig abdecken.<br />
<br />
* Der Baustein soll zwischen verbindlichen, prüfbaren Vorgaben und<br />
unverbindlichen Empfehlungen sprachlich sauber unterscheiden (hier<br />
spielt mein Auditorenblick eine Rolle). Vor allem soll der Baustein<br />
verbindliche Anforderungen auch tatsächlich stellen. Alle<br />
verbindlichen Anforderungen müssen unabhängig von der jeweiligen<br />
Umgebung auch umsetzbar sein, d.h. sie müssen entsprechend generisch<br />
sein.<br />
<br />
* Die Maßnahmen sollen nur in (begründbaren) Ausnahmen zu Empfehlungen<br />
von OWASP im Widerspruch stehen.<br />
<br />
* Die Maßnahmen sollen verständlich und anwendbar sein.</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_German_Chapter_Stammtisch_Initiative&diff=120710OWASP German Chapter Stammtisch Initiative2011-11-25T06:20:38Z<p>Kai Jendrian: </p>
<hr />
<div>== Was ist ein OWASP Stammtisch? ==<br />
<br />
Ein OWASP Stammtisch ist ein regelmäßiges Treffen von OWASP Interessierten in einem Restaurant oder einer Gaststätte. Es gibt zumeist kein festes Programm mit Vorträgen. Der Austausch von Ideen und Erfahrungen soll im Vordergrund stehen. In kleineren Gruppen reicht ein Laptop für Präsentationen, da zumeist keine technischen Möglichkeiten für Vorführungen vorhanden sind. <br />
<br />
Ein lokaler Verantworlicher lädt zum Stammtisch über die German Chapter Mailing Liste ein. Es gelten grundästzlich dieselben [http://www.owasp.org/index.php/Chapter_Rules Regeln wie bei Chapter Meetings]. <br />
<br />
Die lokalen OWASP Stammtische sollen Interessierten Gelegenheit zum Austausch und zum Knüpfen von Kontakten geben. Wenn Sie OWASP selbst kennen lernen wollen, dann besuchen Sie einen Stammtisch in Ihrer Nähe. Wenn es noch keinen gibt, dann gründen Sie einfach einen. <br />
<br />
== Stammtisch oder Chapter? ==<br />
<br />
Stammtische sind keine Konkurrenz für Chapter sondern eine willkommene Ergänzung. Sie ermöglichen regelmäßige Treffen im Rahmen der OWASP-Community ohne die organisatorischen Hürden für einen regulären Chapter-Betrieb. Erreicht ein Stammtisch die "kritische" Masse für einen Chapter-Betrieb, dann ist eine Aufwertung in eine lokale Chapter-Gründung ebenfalls höchst willkommen. <br />
<br />
<br> <br />
<br />
== Lokale Stammtische ==<br />
<br />
==== München ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Münchner Stammtisch findet '''jeden dritten Dienstag im Monat um 19:00 Uhr '''im Restaurant und Biergarten '''"Cafe Waldfrieden"''' in der '''Fürstenrieder Str. 277''' in '''81377 München''' statt. <br> <br />
<br />
Es ist immer für 12 Personen reserviert, bei gutem Wetter (t &gt; 20,0 °C gefühlt, kein Niederschlag, Tageslicht) im Biergarten, bei schlechtem Wetter im Nebenraum - im Zweifelsfall bitte einfach am Tresen nach dem OWASP-Stammtisch fragen. Um vorhergehende '''Anmeldung per Mail bei [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] wird gebeten''', um ggf. weitere Ressourcen reservieren zu lassen - '''spontane "Zaungäste" sind aber jederzeit ebenso willkommen'''. <br />
<br />
===== Der 29. Münchner OWASP Stammtisch am 20.12.2011 =====<br />
<br />
Der Stammtisch im November entfällt leider Ersatzlos. Beschwert Euch bitte bei den Organisatoren des [https://www.owasp.org/index.php/German_OWASP_Day_2011 4. OWASP Day Germany], am besten direkt vor Ort in München während der sicherlich tollen Veranstaltung :-)<br />
<p><br />
Voraussichtliches Dezember-Thema: Die Web Application Security im besonderen Spannungsfeld zwischen Spekulatius und Glühwein unter Berücksichtigung noch zu verbrennender Endjahres-IT-Budgets.<br />
<br />
===== Um 19:00 im <i>"Cafe Waldfrieden"</i> ===== <br />
Cafe Waldfrieden<br><br />
Fürstenrieder Str. 277<br><br />
81377 München<br><br />
<br />
Telefon: (089) 7244 1429<br><br />
<br />
Das Cafe befindet sich direkt gegenüber des Haupteingangs des Waldfriedhofs.<br><br />
<br />
Öffentlicher Nahverkehr: <br />
U-Bahn <b>U6</b>, Haltestelle <b>Holzapfelkreuth</b><br />
oder <b>Stadtbus 151</b>, Haltestelle <b>Waldfriedhof</b> <br />
<br />
Nützliche Links: [http://maps.google.com/maps/place?cid=6980435847828545857 Google Maps, "Places"] oder [http://maps.google.com/maps?q=Fürstenrieder+Straße+277%2C+münchen&btnG=Maps-Suche Google Maps, direkte Adresse] und [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen].<br />
<!--<br />
Georg-Zech-Allee 15<br> 80995 München<br> Tel.: 089 - 31 47 663<br> <br />
<br />
[http://www.schlemmerregion-muenchen.de/rp_restaurant_kurzinfo.afp?!_2RJ1E8VY3&bl=D00&rid=_0S50REUPA&rve=5701B98n Info],[http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=+Georg-Zech-Allee+15,+m%C3%BCnchen&sll=48.140232,11.545644&sspn=0.006801,0.018775&ie=UTF8&ll=48.209117,11.531417&spn=0.006792,0.018775&z=16&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br> <br />
<br />
Gasthaus Löwe und Raute<br> Nymphenburger Str. 64<br> 80335 München<br> Tel. 089 / 130 143 97<br> <br />
<br />
[http://www.loeweundraute.com Homepage], [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=Nymphenburger+Str.+64,+m%C3%BCnchen&sll=53.87844,6.152344&sspn=10.478551,38.012695&ie=UTF8&ll=48.152373,11.548777&spn=0.011567,0.037122&z=15&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br />
--><br />
<br />
===== Geplante Stammtisch-Vorträge =====<br />
<br />
Denkbare Vortrags-Themen an einem der zukünftigen Stammtische: <br />
<br />
*Dein Thema hier! :-)<br />
<br />
Sobald wir eine konkrete Zusage haben, werde ich das bei der Ankündigung des jeweiligen Termins mit bekannt geben.<br> <br />
<br />
Also, wie immer: Ich bitte um kurze Info an mich, ob jemand noch weitere (für uns relevante) Themen parat hat, die er uns näher bringen möchte. ''Verkaufsveranstalter werden alle 20 Minuten ausgebuht und müssen dann eine (neue) Runde Bier bezahlen.''<br><br />
<br />
===== Bereits gehaltene Stammtisch-Vorträge =====<br />
<br />
*Juni 2011: Rückblick und Würdigung der [https://www.owasp.org/index.php/AppSecEU2011 OWASP AppSec Europe 2011 in Dublin] (Andreas von Keviczky)<br />
*Februar 2011: Nachklapp zum [http://www.owasp.org/index.php/Summit_2011/Summit_Results_Summary OWASP Summit 2011 in Portugal] (Achim Hoffmann und Ralf Reinhardt) <br />
*Januar 2011: Offene Diskussion über die Sicherheit von mobilen Endgeräten bei Einsatz im Firmennetz und 'in the wild' (Matthias Trojahn)<br />
*November 2010: Vektorbasierte Anomalien-Erkennung in HTTP-Traffic (Michael Kirchner), [http://students.fh-hagenberg.at/sec/s0810304003/Thesis_Anomalieerkennung_in_HTTP-Daten_Vortrag_OWASP.pdf Folien].<br />
*Juni 2010: Aus der Werkzeug-Schatzkiste des gehobenen Pentesters (Uli Petersen und Achim Hoffmann), u.a. wurde [http://www.owasp.org/index.php/Category:OWASP_EnDe "EnDe"] besprochen.<br />
*März 2010: ISO/IEC 27001 (Barbara Schachner und Feiliang Wu)<br />
*November 2009: Was eine WAF (nicht) kann ([https://mirko.dziadzka.de/ Mirko Dziadzka]), [https://mirko.dziadzka.de/Vortrag/owasp-waf-20091124.pdf Folien]. <br />
*Oktober 2009: Eine Kurzeinführung in Injection-Angriffe (Ralf Reinhardt)<br />
<br />
===== Spread the word =====<br />
<br />
Wie immer möchte ich jeden bitten, der Menschen kennt, von denen er sich vorstellen könnte, dass Sie kommen möchten und könnten, diese Einladung an eben diese Menschen weiter zu leiten.<br> <br />
<br />
Thema und hinreichende Bedingung ist in erster Linie Web Application Security. Man muss überhaupt nichts von OWASP wissen, ein vorhergehender Blick auf die Website indes schadet sicher nicht.<br> <br />
<br />
Schönen Gruß, [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] <br />
<br />
==== Frankfurt ====<br />
<br />
===== Mitorganisator für den Frankfurter Stammtisch gesucht =====<br />
OWASP ist eine aktive Community und zusammen geht alles besser. Damit der Stammtisch regelmäßig stattffinden kann und für die Teilnehmer Planungssicherheit herrscht möchte ich gerne eine Co-Moderatorin oder einen Co-Moderator für die Organisation hinzugewinnen. Das Treffen soll nich gleich ausfallen, wenn der Organisator kurzfristig verhindert ist. Der Arbeitsaufwand ist sehr überschaubar. Eine [https://www.owasp.org/index.php/Membership Mitgliedschaft] bei OWASP ist nicht erforderlich, aber natürlich erwünscht :-) Dann gibt es auch eine "foo.bar@owasp.org" Emailadresse, ein T-Shirt und ein gutes Gefühl. Wer sich dafür interessiert, möge sich bitte bei [mailto:boris@owasp.org Boris Hemkemeier] melden oder direkt auf die [https://www.owasp.org/index.php/Membership Membership Seite] gehen.<br />
===== Allgemeines =====<br />
<br />
Ähnlich wie in München soll der Stammtisch hauptsächlich zum lockeren Austausch und Netzwerken dienen. <br />
<br />
Eingeladen sind alle Interessierten an <br />
<br />
*Application Security <br />
*Web Application Security <br />
*Secure Software Lifecycle <br />
*Security-Awareness Programme für Entwickler, Tester, Architekten und Auftraggeber <br />
*Security Management von Anwendungen im Unternehmen <br />
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten <br />
*Anwendungssicherheit und Metriken <br />
*und natürlich an OWASP selbst.<br />
<br />
Es soll keine Hardcore Hacker Veranstaltung sein. Viele werden mit IT-Security konfrontiert und suchen Lösungen für sichere Anwendungen. Technische Themen sind natürlich auch erwünscht. Dafür können wir eigenen Termine auf dem Stammtisch planen.<br />
<br />
===== Der 4. Frankfurter OWASP Stammtisch findet am 23.11.2011 statt =====<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 23.11.2011. Für das folgende Treffen ist der 25.01.2012 geplant.<br />
<br />
ACHTUNG: Der 4. OWASP Stammtisch Frankfurt wird im [http://www.depot1899.de/ Depot 1899] in der [http://j.mp/uHFH9X Textorstraße 33, 60594 Frankfurt am Main] stattfinden. Wir testen gerade Lokale aus in denen man vielleicht auch einmal einen Vortrag halten kann mit anschließender Diskussion.<br />
<br />
Bei diesem Treffen stehen nebem dem Kennenlernen die letzen OWASP Konferenzen im Vordergrund. Wir werden einen Bericht vom German OWASP Day am 17.11.2011 haben und eventuell auch einen von der OWASP AppSec US: Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/inu2mt2sngx7dzs4 Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
===== Der 3. Frankfurter OWASP Stammtisch findet am 21.09.2011 statt =====<br />
<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 21.09.2011. Für das folgende Treffen ist der 23.11.2011 geplant.<br />
<br />
Der 3. OWASP Stammtisch Frankfurt wird wieder in der [http://j.mp/piQdaP Arche Nova, Kasseler Str. 1a, Frankfurt a.M.] stattfinden. <br />
<br />
Bei diesem Treffen steht wieder das Kennenlernen im Vordergrund. Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/77m7p3qama2u723z Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
==== Stuttgart ====<br />
<br />
===== Der Stammtisch findet jeden ersten Montag jeden zweiten Monat statt. =====<br />
<br />
Wir treffen uns jeweils um 19 Uhr im [http://www.sportpark-neuwirtshaus.de/ Sportrestaurant Neuwirtshaus], Neuwirtshausstrasse 199a 70439 Stuttgart. Wer mit dem ÖPNV anreist (S-Bahn Haltestelle Porsche) kann sich per E-Mail mit der Ankunftszeit melden, es gibt dann einen Fahrdienst &nbsp;:) <br />
<br />
Derzeit sind wir insgesamt rund 10 Personen und freuen uns auf weitere Teilnehmer. Zu jedem Termin wird ein Vortrag zum Besten gegeben, Wünsche jederzeit gerne. Um vorhergehende Anmeldung per [mailto:tobias.glemser@owasp.org E-Mail] wird gebeten, wer das verschwitzt darf aber natürlich auch kommen. Bei Fragen zum Stammtisch einfach kurz anschreiben. <br />
<br />
Der Stammtisch wird hier, über die OWASP-Germany Mailingliste und [https://www.xing.com/profile/Tobias_Glemser Xing] (einfach mit mir verknüpfen) angekündigt. <br />
<br />
Wir freuen uns auf Euer Kommen! <br />
<br />
Tobias <br />
<br />
'''Termine:''' <br />
<br />
*'''Termin Oktober fällt aufgrund it-sa aus, Anfang November wegen OWASP Day Germany'''<br />
<br />
*'''21.11.11''' <br />
<br />
:Programm: <br />
:*19.00h Beginn <br />
:*19.30h - t.b.a.<br />
<br />
----<br />
<br />
'''Rückblick '''<br> <br />
*01.08.2011. 10. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Vortrag "Neuerungen in Burp Pro 1.4", Michael Schäfer (Schutzwerk GmbH). Bilder von der Riesenjubiläumsparty im Anschluss müssen leider unter Verschluss gehalten werden. "What happens at Stammtisch, stays at Stammtisch". Achja: Grüße an die Vegas-Reisenden unter uns, die deswegen die Sause verpasst haben :)<br />
*06.06.2011. 9. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzfristige Absagen (unter anderem des Referenten) taten der Stimmung keinen Abbruch. Sehr interessante Diskussionen über Passwortsicherheit, RSA Token Security und anderes.<br />
*04.04.2011. 8. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Der bestbesuchteste Stuttgarter Stammtisch bisher. Die insgesamt 13 Teilnehmer diskutierten über den Vortrag von [http://webuser.hs-furtwangen.de/~doelitz/index.html Frank Dölitzscher] (Hochschule Furtwangen) zu einem Cloud-Frontend mit Single-Sign-On Anbindung und SSH-Key Erstellung [[File:2011-04-04_CloudIA_WebGUI_OWASP_Stammtisch_Stuttgart.pdf|Folien]] interessiert zu. Insbesondere wurden mögliche Schwachstellen der Implementierung der Lösung und des Java-Client zur SSH-Key Erstellung besprochen. Für beide Seiten ein Gewinn :)<br />
<br />
:Antworten von Frank bzgl. der offenen Fragen:<br />
:"- In der Version des Shibb-Idp den wir verwenden ist ein zwingender Restart beim Einlesen einer neuen Config notwendig. Die Konfiguration ist dateibasiert und gliedert sich in 3 Dateien:<br />
<br />
:a) Relying Party - regelt Förderation (Verweis auf MetaData)<br />
:b) MeTaData - Beinhaltet alle SPs mit Links darauf, Metadaten der einzelnen SP<br />
:c) AttributeFilter.xml - Regelt welche Userattribute werden einem SP nach erfolgreicher Autorisierung übermittelt<br />
<br />
:Die kritische Datei ist die AttributeFilter.xml.<br />
:In der aktuellsten Shibboleth Version sollte ein einfacher Reload der Konfigurationen auch prinzipiell möglich sein. Allerdings warnen die Entwickler vor einem Produktiveinsatz: "Caution Do NOT enable configuration reloading in a production environment unless you have a rigorous configuration testing process in place and used."<br />
<br />
: Siehe: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig<br />
<br />
:Unser aktueller Idp wurde inzwischen auf einen größeren Server umgezogen. Ein Restart dauert nun etwa 25 Sekunden. Das ist zwar deutlich schneller als zuvor (1,5min) allerdings für das Cloud-Szenario immer noch nicht praktikabel.<br />
<br />
:Zur Erreichbarkeit der VMs untereinander: Die VMs akzeptieren nur Incoming Traffic vom Reverse-Proxy (SP)."<br />
<br />
:[[Image:2011-04-04-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*07.02.2011. 7. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzdiskussion: "Brauchen wir ein Security-Framework Verwaltungs-Protokoll?"<br />
<br />
*08.11.2010. 6. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Nanu, wieder kein Vortag, aber beschwert hat sich auch niemand :)<br />
<br />
*06.09.2010. 5. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Leider kein Vortrag, aber eine launige Runde. Wer schon immer wissen wollte was Globolis, Pferde und die Goonies mit IT-Security zu tun haben oder wie die Visitenkarte von Kevin Mitnick aussieht, der ist bei uns einfach genau richtig..<br />
<br />
*07.06.2010. 4. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:Neuigkeiten vom Chapter Meeting im Mai 2010 <br />
:Vorstellung und Erfahrungsberichte mit den kommerziellen Tools HP Webinspect (Andy Kurtz) und Acunetix (Tobias Glemser). Keine Folien da "Freestyle". Kurzfazit war: Beide Tools bilden ein ähnliches Featureset ab, um manuelles Testen kommt man niemals rum.<br />
<br />
:[[Image:2010-06-07-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*12.04.2010. 3. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:[[Media:OWASP_Stammtisch_20100412.ppt|Vortrag "WATOBO - Web Application Toolbox"]] von Andreas Schmidt. Vorstellung eines selbst entwickeltes Werkzeugs ([http://watobo.sf.net WATOBO - Web Application Toolbox]) zur Überpruefung von Webapplikationen. Das Tool selbst ist unter der GNU Public License veröffentlicht und soll Sicherheitsspezialisten bei der Durchführung von semi-automatisierten Sicherheitsanalysen unterstützen.<br />
<br />
*01.02.2010. 2. OWASP German Chapter Stammtisch Stuttgart<br />
<br />
:Vortrag Vorstellung OWASP Whitepaper von Tobias Glemser "[[Best Practice: Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]"<br><br />
<br />
*30.11.2009. 1. OWASP German Chapter Stammtisch Stuttgart<br><br />
<br />
:Das erste Treffen diente dem Beschnuppern und gemeinsamen Pläne schmieden für die nächsten Male<br><br />
<br />
<br> <br />
<br />
==== Düsseldorf ====<br />
<br />
===== Coming soon! =====<br />
<br />
Vorgeschlagen von: Sven Schlüter <br> //TODO <br />
<br />
==== Köln ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Kölner Stammtisch trifft sich zur Zeit alle zwei Monate. Es ist geplant zwischen Vorträgen und lockeren Diskussionen zu alternieren. Jeder ist herzlich willkommen und kann gerne noch Freunde, Kollegen, Interessierte mitbringen. <br />
<br />
<br> <br />
<br />
===== 8. Kölner OWASP Stammtisch am 27.10.2011 =====<br />
<br />
Wir treffen uns zum achten Kölner Stammtisch am 27.10.2011 um '''19:00Uhr'''. <br />
<br />
Diesmal wieder im [http://www.haus-toeller.de/ Brauhaus Töller] in der Weyerstraße.<br />
<br />
Bitte gebt mir noch eine [mailto:ralf.allar@owasp.org Rückmeldung], falls ihr kommt, damit ich einen Überblick über die Zahl der Anwesenden erhalte. Danke! <br />
<br />
<br />
==== Hamburg ====<br />
<br />
<br />
===== Generelles =====<br />
<br />
Wer und Interesse hat mitzuwirken oder mitgestalten möchte, bitte bei Dirk Wetter melden (dirk punkt wetter aet owasp punkt org). Besonders Vorträge plus Vortragende sind gefragt. Ansonsten werden die Treffen natürlich über die [https://lists.owasp.org/mailman/listinfo/owasp-germany/ OWASP-Deutschland-Liste] angekündigt. <br />
<br />
===== Fünftes Treffen am 13.9.2011 =====<br />
<br />
* Uhrzeit: 20 Uhr<br />
* Vortrag von Dirk Kollberg (Sophos)/Toralv Dirro (McAfee) "Sicherheits-Ratatouille: Eine bunte Mischung mit Zutaten aus Sozialen Netzen, neues aus der Welt der Online-Banking-Trojaner und vieles mehr"<br />
* Ort: Lehmanns Fachbuchhandlung, Kurze Mühren 6 (.i.d. Nähe des Hbf)<br />
* [https://lists.owasp.org/pipermail/owasp-germany/2011-August/000303.html Abstract] von der Mailingliste<br />
<br />
===== Viertes Treffen am 14.4.2011 =====<br />
<br />
* Vortrag von Tim Sattler: "Sicherheit in der Cloud - Chancen und Risiken". <br ><br />
* Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
* [http://www.guug.de/lokal/hamburg/talks/OWASP_Sicherheit_in_der_Cloud.pdf Slides]<br />
<br />
===== Drittes Treffen am 7.3.2011 =====<br />
<br />
Den Rosenmontag begehen wir im Norden mit einem Konkurrenzprogramm: Gemütlicher OWASP-Abend mit sinnieren über die Websicherheit in <i>Omas Apotheke</i> in der Schanze. Los geht's um 19 Uhr. <br />
<br />
===== Zweites Treffen inkl. Vortrag am 14.10.2010 =====<br />
<br />
VortragsthemaÖ "OWASP Top 10 - Wat nu?" <br />
[http://drwetter.eu/talks/OWASP_T10-Wat-nu.pdf Slides]<br><br />
Datum/Zeit: 14.10.2010, 19 Uhr<br><br />
Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
Vortragender: Dirk Wetter<br><br><br />
<br />
===== Erstes Treffen am 8.7.2010 =====<br />
<br />
Wir treffen uns erstmalig am '''8.7.2010 um 19 Uhr''' auf [http://maps.google.de/maps?q=strandpauli&um=1&ie=UTF-8&sa=N&hl=en&tab=wl Strandpauli], einem der Beachclubs mit Aussicht auf den schönen Hamburger Hafen. Der 8.7. ist der erste Ferientag in HH und fußballfrei. <br> Inhalt des ersten Treffens ist eher ein Informationsaustausch: Neben etwas Networking wäre es prima, Erwartungen zu diskutieren und vielleicht die ersten Vorträge zu planen. Da das in dem Etablissement im Sommer dort wahrscheinlich nicht ganz leer sein wird und der Beachclub sicherlich nicht auf den OWASP-Stammtisch wartet&nbsp;;-) wird wärmstens empfohlen, bis zum 7.7. morgens Dirk Wetter sich anzumelden, der dann die Reservierung vornimmt. Sonst muss man halt stehen.&nbsp;;-) <br />
<br> <br />
Mindestens einer wird ein OWASP-T-Shirt tragen. (Hint: Das Logo ist auch auf dieser Webseite zu finden).<br />
<br />
==== Karlsruhe ====<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 15.12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, haben wir den Termin per Doodle ermittelt: http://www.doodle.com/we5eqvx3eq3c7fnm.<br />
<br />
Treffpunkt wird am Donnerstag, 15.12.2011 um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
==== Nürnberg ====<br />
<br />
===== Zweiter Stammtisch =====<br />
<br />
Ein zweiter Stammtisch für den Raum Nürnberg, Fürth und Erlangen soll November oder Dezember stattfinden!<br />
<br />
Termin: möglichst noch im Dezember, sonst Anfang 2012<br />
<br />
Ort: Gaststätte in der Nürnberger Innenstadt<br />
<br />
===== Organisatorisches =====<br />
<br />
Bei Interesse bitte bei [mailto:heiko.richler@owasp.org Heiko Richler] melden. Willkommen ist jeder! Wer nur dieses mal nicht kann oder wem Erlangen oder Fürth lieber wären bitte auch melden!<br />
<br />
<headertabs /></div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_German_Chapter_Stammtisch_Initiative&diff=120637OWASP German Chapter Stammtisch Initiative2011-11-23T06:56:33Z<p>Kai Jendrian: </p>
<hr />
<div>== Was ist ein OWASP Stammtisch? ==<br />
<br />
Ein OWASP Stammtisch ist ein regelmäßiges Treffen von OWASP Interessierten in einem Restaurant oder einer Gaststätte. Es gibt zumeist kein festes Programm mit Vorträgen. Der Austausch von Ideen und Erfahrungen soll im Vordergrund stehen. In kleineren Gruppen reicht ein Laptop für Präsentationen, da zumeist keine technischen Möglichkeiten für Vorführungen vorhanden sind. <br />
<br />
Ein lokaler Verantworlicher lädt zum Stammtisch über die German Chapter Mailing Liste ein. Es gelten grundästzlich dieselben [http://www.owasp.org/index.php/Chapter_Rules Regeln wie bei Chapter Meetings]. <br />
<br />
Die lokalen OWASP Stammtische sollen Interessierten Gelegenheit zum Austausch und zum Knüpfen von Kontakten geben. Wenn Sie OWASP selbst kennen lernen wollen, dann besuchen Sie einen Stammtisch in Ihrer Nähe. Wenn es noch keinen gibt, dann gründen Sie einfach einen. <br />
<br />
== Stammtisch oder Chapter? ==<br />
<br />
Stammtische sind keine Konkurrenz für Chapter sondern eine willkommene Ergänzung. Sie ermöglichen regelmäßige Treffen im Rahmen der OWASP-Community ohne die organisatorischen Hürden für einen regulären Chapter-Betrieb. Erreicht ein Stammtisch die "kritische" Masse für einen Chapter-Betrieb, dann ist eine Aufwertung in eine lokale Chapter-Gründung ebenfalls höchst willkommen. <br />
<br />
<br> <br />
<br />
== Lokale Stammtische ==<br />
<br />
==== München ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Münchner Stammtisch findet '''jeden dritten Dienstag im Monat um 19:00 Uhr '''im Restaurant und Biergarten '''"Cafe Waldfrieden"''' in der '''Fürstenrieder Str. 277''' in '''81377 München''' statt. <br> <br />
<br />
Es ist immer für 12 Personen reserviert, bei gutem Wetter (t &gt; 20,0 °C gefühlt, kein Niederschlag, Tageslicht) im Biergarten, bei schlechtem Wetter im Nebenraum - im Zweifelsfall bitte einfach am Tresen nach dem OWASP-Stammtisch fragen. Um vorhergehende '''Anmeldung per Mail bei [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] wird gebeten''', um ggf. weitere Ressourcen reservieren zu lassen - '''spontane "Zaungäste" sind aber jederzeit ebenso willkommen'''. <br />
<br />
===== Der 29. Münchner OWASP Stammtisch am 20.12.2011 =====<br />
<br />
Der Stammtisch im November entfällt leider Ersatzlos. Beschwert Euch bitte bei den Organisatoren des [https://www.owasp.org/index.php/German_OWASP_Day_2011 4. OWASP Day Germany], am besten direkt vor Ort in München während der sicherlich tollen Veranstaltung :-)<br />
<p><br />
Voraussichtliches Dezember-Thema: Die Web Application Security im besonderen Spannungsfeld zwischen Spekulatius und Glühwein unter Berücksichtigung noch zu verbrennender Endjahres-IT-Budgets.<br />
<br />
===== Um 19:00 im <i>"Cafe Waldfrieden"</i> ===== <br />
Cafe Waldfrieden<br><br />
Fürstenrieder Str. 277<br><br />
81377 München<br><br />
<br />
Telefon: (089) 7244 1429<br><br />
<br />
Das Cafe befindet sich direkt gegenüber des Haupteingangs des Waldfriedhofs.<br><br />
<br />
Öffentlicher Nahverkehr: <br />
U-Bahn <b>U6</b>, Haltestelle <b>Holzapfelkreuth</b><br />
oder <b>Stadtbus 151</b>, Haltestelle <b>Waldfriedhof</b> <br />
<br />
Nützliche Links: [http://maps.google.com/maps/place?cid=6980435847828545857 Google Maps, "Places"] oder [http://maps.google.com/maps?q=Fürstenrieder+Straße+277%2C+münchen&btnG=Maps-Suche Google Maps, direkte Adresse] und [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen].<br />
<!--<br />
Georg-Zech-Allee 15<br> 80995 München<br> Tel.: 089 - 31 47 663<br> <br />
<br />
[http://www.schlemmerregion-muenchen.de/rp_restaurant_kurzinfo.afp?!_2RJ1E8VY3&bl=D00&rid=_0S50REUPA&rve=5701B98n Info],[http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=+Georg-Zech-Allee+15,+m%C3%BCnchen&sll=48.140232,11.545644&sspn=0.006801,0.018775&ie=UTF8&ll=48.209117,11.531417&spn=0.006792,0.018775&z=16&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br> <br />
<br />
Gasthaus Löwe und Raute<br> Nymphenburger Str. 64<br> 80335 München<br> Tel. 089 / 130 143 97<br> <br />
<br />
[http://www.loeweundraute.com Homepage], [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=Nymphenburger+Str.+64,+m%C3%BCnchen&sll=53.87844,6.152344&sspn=10.478551,38.012695&ie=UTF8&ll=48.152373,11.548777&spn=0.011567,0.037122&z=15&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br />
--><br />
<br />
===== Geplante Stammtisch-Vorträge =====<br />
<br />
Denkbare Vortrags-Themen an einem der zukünftigen Stammtische: <br />
<br />
*Dein Thema hier! :-)<br />
<br />
Sobald wir eine konkrete Zusage haben, werde ich das bei der Ankündigung des jeweiligen Termins mit bekannt geben.<br> <br />
<br />
Also, wie immer: Ich bitte um kurze Info an mich, ob jemand noch weitere (für uns relevante) Themen parat hat, die er uns näher bringen möchte. ''Verkaufsveranstalter werden alle 20 Minuten ausgebuht und müssen dann eine (neue) Runde Bier bezahlen.''<br><br />
<br />
===== Bereits gehaltene Stammtisch-Vorträge =====<br />
<br />
*Juni 2011: Rückblick und Würdigung der [https://www.owasp.org/index.php/AppSecEU2011 OWASP AppSec Europe 2011 in Dublin] (Andreas von Keviczky)<br />
*Februar 2011: Nachklapp zum [http://www.owasp.org/index.php/Summit_2011/Summit_Results_Summary OWASP Summit 2011 in Portugal] (Achim Hoffmann und Ralf Reinhardt) <br />
*Januar 2011: Offene Diskussion über die Sicherheit von mobilen Endgeräten bei Einsatz im Firmennetz und 'in the wild' (Matthias Trojahn)<br />
*November 2010: Vektorbasierte Anomalien-Erkennung in HTTP-Traffic (Michael Kirchner), [http://students.fh-hagenberg.at/sec/s0810304003/Thesis_Anomalieerkennung_in_HTTP-Daten_Vortrag_OWASP.pdf Folien].<br />
*Juni 2010: Aus der Werkzeug-Schatzkiste des gehobenen Pentesters (Uli Petersen und Achim Hoffmann), u.a. wurde [http://www.owasp.org/index.php/Category:OWASP_EnDe "EnDe"] besprochen.<br />
*März 2010: ISO/IEC 27001 (Barbara Schachner und Feiliang Wu)<br />
*November 2009: Was eine WAF (nicht) kann ([https://mirko.dziadzka.de/ Mirko Dziadzka]), [https://mirko.dziadzka.de/Vortrag/owasp-waf-20091124.pdf Folien]. <br />
*Oktober 2009: Eine Kurzeinführung in Injection-Angriffe (Ralf Reinhardt)<br />
<br />
===== Spread the word =====<br />
<br />
Wie immer möchte ich jeden bitten, der Menschen kennt, von denen er sich vorstellen könnte, dass Sie kommen möchten und könnten, diese Einladung an eben diese Menschen weiter zu leiten.<br> <br />
<br />
Thema und hinreichende Bedingung ist in erster Linie Web Application Security. Man muss überhaupt nichts von OWASP wissen, ein vorhergehender Blick auf die Website indes schadet sicher nicht.<br> <br />
<br />
Schönen Gruß, [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] <br />
<br />
==== Frankfurt ====<br />
<br />
===== Mitorganisator für den Frankfurter Stammtisch gesucht =====<br />
OWASP ist eine aktive Community und zusammen geht alles besser. Damit der Stammtisch regelmäßig stattffinden kann und für die Teilnehmer Planungssicherheit herrscht möchte ich gerne eine Co-Moderatorin oder einen Co-Moderator für die Organisation hinzugewinnen. Das Treffen soll nich gleich ausfallen, wenn der Organisator kurzfristig verhindert ist. Der Arbeitsaufwand ist sehr überschaubar. Eine [https://www.owasp.org/index.php/Membership Mitgliedschaft] bei OWASP ist nicht erforderlich, aber natürlich erwünscht :-) Dann gibt es auch eine "foo.bar@owasp.org" Emailadresse, ein T-Shirt und ein gutes Gefühl. Wer sich dafür interessiert, möge sich bitte bei [mailto:boris@owasp.org Boris Hemkemeier] melden oder direkt auf die [https://www.owasp.org/index.php/Membership Membership Seite] gehen.<br />
===== Allgemeines =====<br />
<br />
Ähnlich wie in München soll der Stammtisch hauptsächlich zum lockeren Austausch und Netzwerken dienen. <br />
<br />
Eingeladen sind alle Interessierten an <br />
<br />
*Application Security <br />
*Web Application Security <br />
*Secure Software Lifecycle <br />
*Security-Awareness Programme für Entwickler, Tester, Architekten und Auftraggeber <br />
*Security Management von Anwendungen im Unternehmen <br />
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten <br />
*Anwendungssicherheit und Metriken <br />
*und natürlich an OWASP selbst.<br />
<br />
Es soll keine Hardcore Hacker Veranstaltung sein. Viele werden mit IT-Security konfrontiert und suchen Lösungen für sichere Anwendungen. Technische Themen sind natürlich auch erwünscht. Dafür können wir eigenen Termine auf dem Stammtisch planen.<br />
<br />
===== Der 4. Frankfurter OWASP Stammtisch findet am 23.11.2011 statt =====<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 23.11.2011. Für das folgende Treffen ist der 25.01.2012 geplant.<br />
<br />
ACHTUNG: Der 4. OWASP Stammtisch Frankfurt wird im [http://www.depot1899.de/ Depot 1899] in der [http://j.mp/uHFH9X Textorstraße 33, 60594 Frankfurt am Main] stattfinden. Wir testen gerade Lokale aus in denen man vielleicht auch einmal einen Vortrag halten kann mit anschließender Diskussion.<br />
<br />
Bei diesem Treffen stehen nebem dem Kennenlernen die letzen OWASP Konferenzen im Vordergrund. Wir werden einen Bericht vom German OWASP Day am 17.11.2011 haben und eventuell auch einen von der OWASP AppSec US: Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/inu2mt2sngx7dzs4 Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
===== Der 3. Frankfurter OWASP Stammtisch findet am 21.09.2011 statt =====<br />
<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 21.09.2011. Für das folgende Treffen ist der 23.11.2011 geplant.<br />
<br />
Der 3. OWASP Stammtisch Frankfurt wird wieder in der [http://j.mp/piQdaP Arche Nova, Kasseler Str. 1a, Frankfurt a.M.] stattfinden. <br />
<br />
Bei diesem Treffen steht wieder das Kennenlernen im Vordergrund. Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/77m7p3qama2u723z Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
==== Stuttgart ====<br />
<br />
===== Der Stammtisch findet jeden ersten Montag jeden zweiten Monat statt. =====<br />
<br />
Wir treffen uns jeweils um 19 Uhr im [http://www.sportpark-neuwirtshaus.de/ Sportrestaurant Neuwirtshaus], Neuwirtshausstrasse 199a 70439 Stuttgart. Wer mit dem ÖPNV anreist (S-Bahn Haltestelle Porsche) kann sich per E-Mail mit der Ankunftszeit melden, es gibt dann einen Fahrdienst &nbsp;:) <br />
<br />
Derzeit sind wir insgesamt rund 10 Personen und freuen uns auf weitere Teilnehmer. Zu jedem Termin wird ein Vortrag zum Besten gegeben, Wünsche jederzeit gerne. Um vorhergehende Anmeldung per [mailto:tobias.glemser@owasp.org E-Mail] wird gebeten, wer das verschwitzt darf aber natürlich auch kommen. Bei Fragen zum Stammtisch einfach kurz anschreiben. <br />
<br />
Der Stammtisch wird hier, über die OWASP-Germany Mailingliste und [https://www.xing.com/profile/Tobias_Glemser Xing] (einfach mit mir verknüpfen) angekündigt. <br />
<br />
Wir freuen uns auf Euer Kommen! <br />
<br />
Tobias <br />
<br />
'''Termine:''' <br />
<br />
*'''Termin Oktober fällt aufgrund it-sa aus, Anfang November wegen OWASP Day Germany'''<br />
<br />
*'''21.11.11''' <br />
<br />
:Programm: <br />
:*19.00h Beginn <br />
:*19.30h - t.b.a.<br />
<br />
----<br />
<br />
'''Rückblick '''<br> <br />
*01.08.2011. 10. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Vortrag "Neuerungen in Burp Pro 1.4", Michael Schäfer (Schutzwerk GmbH). Bilder von der Riesenjubiläumsparty im Anschluss müssen leider unter Verschluss gehalten werden. "What happens at Stammtisch, stays at Stammtisch". Achja: Grüße an die Vegas-Reisenden unter uns, die deswegen die Sause verpasst haben :)<br />
*06.06.2011. 9. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzfristige Absagen (unter anderem des Referenten) taten der Stimmung keinen Abbruch. Sehr interessante Diskussionen über Passwortsicherheit, RSA Token Security und anderes.<br />
*04.04.2011. 8. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Der bestbesuchteste Stuttgarter Stammtisch bisher. Die insgesamt 13 Teilnehmer diskutierten über den Vortrag von [http://webuser.hs-furtwangen.de/~doelitz/index.html Frank Dölitzscher] (Hochschule Furtwangen) zu einem Cloud-Frontend mit Single-Sign-On Anbindung und SSH-Key Erstellung [[File:2011-04-04_CloudIA_WebGUI_OWASP_Stammtisch_Stuttgart.pdf|Folien]] interessiert zu. Insbesondere wurden mögliche Schwachstellen der Implementierung der Lösung und des Java-Client zur SSH-Key Erstellung besprochen. Für beide Seiten ein Gewinn :)<br />
<br />
:Antworten von Frank bzgl. der offenen Fragen:<br />
:"- In der Version des Shibb-Idp den wir verwenden ist ein zwingender Restart beim Einlesen einer neuen Config notwendig. Die Konfiguration ist dateibasiert und gliedert sich in 3 Dateien:<br />
<br />
:a) Relying Party - regelt Förderation (Verweis auf MetaData)<br />
:b) MeTaData - Beinhaltet alle SPs mit Links darauf, Metadaten der einzelnen SP<br />
:c) AttributeFilter.xml - Regelt welche Userattribute werden einem SP nach erfolgreicher Autorisierung übermittelt<br />
<br />
:Die kritische Datei ist die AttributeFilter.xml.<br />
:In der aktuellsten Shibboleth Version sollte ein einfacher Reload der Konfigurationen auch prinzipiell möglich sein. Allerdings warnen die Entwickler vor einem Produktiveinsatz: "Caution Do NOT enable configuration reloading in a production environment unless you have a rigorous configuration testing process in place and used."<br />
<br />
: Siehe: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig<br />
<br />
:Unser aktueller Idp wurde inzwischen auf einen größeren Server umgezogen. Ein Restart dauert nun etwa 25 Sekunden. Das ist zwar deutlich schneller als zuvor (1,5min) allerdings für das Cloud-Szenario immer noch nicht praktikabel.<br />
<br />
:Zur Erreichbarkeit der VMs untereinander: Die VMs akzeptieren nur Incoming Traffic vom Reverse-Proxy (SP)."<br />
<br />
:[[Image:2011-04-04-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*07.02.2011. 7. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzdiskussion: "Brauchen wir ein Security-Framework Verwaltungs-Protokoll?"<br />
<br />
*08.11.2010. 6. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Nanu, wieder kein Vortag, aber beschwert hat sich auch niemand :)<br />
<br />
*06.09.2010. 5. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Leider kein Vortrag, aber eine launige Runde. Wer schon immer wissen wollte was Globolis, Pferde und die Goonies mit IT-Security zu tun haben oder wie die Visitenkarte von Kevin Mitnick aussieht, der ist bei uns einfach genau richtig..<br />
<br />
*07.06.2010. 4. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:Neuigkeiten vom Chapter Meeting im Mai 2010 <br />
:Vorstellung und Erfahrungsberichte mit den kommerziellen Tools HP Webinspect (Andy Kurtz) und Acunetix (Tobias Glemser). Keine Folien da "Freestyle". Kurzfazit war: Beide Tools bilden ein ähnliches Featureset ab, um manuelles Testen kommt man niemals rum.<br />
<br />
:[[Image:2010-06-07-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*12.04.2010. 3. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:[[Media:OWASP_Stammtisch_20100412.ppt|Vortrag "WATOBO - Web Application Toolbox"]] von Andreas Schmidt. Vorstellung eines selbst entwickeltes Werkzeugs ([http://watobo.sf.net WATOBO - Web Application Toolbox]) zur Überpruefung von Webapplikationen. Das Tool selbst ist unter der GNU Public License veröffentlicht und soll Sicherheitsspezialisten bei der Durchführung von semi-automatisierten Sicherheitsanalysen unterstützen.<br />
<br />
*01.02.2010. 2. OWASP German Chapter Stammtisch Stuttgart<br />
<br />
:Vortrag Vorstellung OWASP Whitepaper von Tobias Glemser "[[Best Practice: Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]"<br><br />
<br />
*30.11.2009. 1. OWASP German Chapter Stammtisch Stuttgart<br><br />
<br />
:Das erste Treffen diente dem Beschnuppern und gemeinsamen Pläne schmieden für die nächsten Male<br><br />
<br />
<br> <br />
<br />
==== Düsseldorf ====<br />
<br />
===== Coming soon! =====<br />
<br />
Vorgeschlagen von: Sven Schlüter <br> //TODO <br />
<br />
==== Köln ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Kölner Stammtisch trifft sich zur Zeit alle zwei Monate. Es ist geplant zwischen Vorträgen und lockeren Diskussionen zu alternieren. Jeder ist herzlich willkommen und kann gerne noch Freunde, Kollegen, Interessierte mitbringen. <br />
<br />
<br> <br />
<br />
===== 8. Kölner OWASP Stammtisch am 27.10.2011 =====<br />
<br />
Wir treffen uns zum achten Kölner Stammtisch am 27.10.2011 um '''19:00Uhr'''. <br />
<br />
Diesmal wieder im [http://www.haus-toeller.de/ Brauhaus Töller] in der Weyerstraße.<br />
<br />
Bitte gebt mir noch eine [mailto:ralf.allar@owasp.org Rückmeldung], falls ihr kommt, damit ich einen Überblick über die Zahl der Anwesenden erhalte. Danke! <br />
<br />
<br />
==== Hamburg ====<br />
<br />
<br />
===== Generelles =====<br />
<br />
Wer und Interesse hat mitzuwirken oder mitgestalten möchte, bitte bei Dirk Wetter melden (dirk punkt wetter aet owasp punkt org). Besonders Vorträge plus Vortragende sind gefragt. Ansonsten werden die Treffen natürlich über die [https://lists.owasp.org/mailman/listinfo/owasp-germany/ OWASP-Deutschland-Liste] angekündigt. <br />
<br />
===== Fünftes Treffen am 13.9.2011 =====<br />
<br />
* Uhrzeit: 20 Uhr<br />
* Vortrag von Dirk Kollberg (Sophos)/Toralv Dirro (McAfee) "Sicherheits-Ratatouille: Eine bunte Mischung mit Zutaten aus Sozialen Netzen, neues aus der Welt der Online-Banking-Trojaner und vieles mehr"<br />
* Ort: Lehmanns Fachbuchhandlung, Kurze Mühren 6 (.i.d. Nähe des Hbf)<br />
* [https://lists.owasp.org/pipermail/owasp-germany/2011-August/000303.html Abstract] von der Mailingliste<br />
<br />
===== Viertes Treffen am 14.4.2011 =====<br />
<br />
* Vortrag von Tim Sattler: "Sicherheit in der Cloud - Chancen und Risiken". <br ><br />
* Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
* [http://www.guug.de/lokal/hamburg/talks/OWASP_Sicherheit_in_der_Cloud.pdf Slides]<br />
<br />
===== Drittes Treffen am 7.3.2011 =====<br />
<br />
Den Rosenmontag begehen wir im Norden mit einem Konkurrenzprogramm: Gemütlicher OWASP-Abend mit sinnieren über die Websicherheit in <i>Omas Apotheke</i> in der Schanze. Los geht's um 19 Uhr. <br />
<br />
===== Zweites Treffen inkl. Vortrag am 14.10.2010 =====<br />
<br />
VortragsthemaÖ "OWASP Top 10 - Wat nu?" <br />
[http://drwetter.eu/talks/OWASP_T10-Wat-nu.pdf Slides]<br><br />
Datum/Zeit: 14.10.2010, 19 Uhr<br><br />
Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
Vortragender: Dirk Wetter<br><br><br />
<br />
===== Erstes Treffen am 8.7.2010 =====<br />
<br />
Wir treffen uns erstmalig am '''8.7.2010 um 19 Uhr''' auf [http://maps.google.de/maps?q=strandpauli&um=1&ie=UTF-8&sa=N&hl=en&tab=wl Strandpauli], einem der Beachclubs mit Aussicht auf den schönen Hamburger Hafen. Der 8.7. ist der erste Ferientag in HH und fußballfrei. <br> Inhalt des ersten Treffens ist eher ein Informationsaustausch: Neben etwas Networking wäre es prima, Erwartungen zu diskutieren und vielleicht die ersten Vorträge zu planen. Da das in dem Etablissement im Sommer dort wahrscheinlich nicht ganz leer sein wird und der Beachclub sicherlich nicht auf den OWASP-Stammtisch wartet&nbsp;;-) wird wärmstens empfohlen, bis zum 7.7. morgens Dirk Wetter sich anzumelden, der dann die Reservierung vornimmt. Sonst muss man halt stehen.&nbsp;;-) <br />
<br> <br />
Mindestens einer wird ein OWASP-T-Shirt tragen. (Hint: Das Logo ist auch auf dieser Webseite zu finden).<br />
<br />
==== Karlsruhe ====<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 1[235].12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, steht der Termin noch nicht genau fest, sondern soll über Doodle ermittelt werden: http://www.doodle.com/we5eqvx3eq3c7fnm<br />
<br />
Treffpunkt wird an dem gewählten Termin um 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
==== Nürnberg ====<br />
<br />
===== Zweiter Stammtisch =====<br />
<br />
Ein zweiter Stammtisch für den Raum Nürnberg, Fürth und Erlangen soll November oder Dezember stattfinden!<br />
<br />
Termin: möglichst noch im Dezember, sonst Anfang 2012<br />
<br />
Ort: Gaststätte in der Nürnberger Innenstadt<br />
<br />
===== Organisatorisches =====<br />
<br />
Bei Interesse bitte bei [mailto:heiko.richler@owasp.org Heiko Richler] melden. Willkommen ist jeder! Wer nur dieses mal nicht kann oder wem Erlangen oder Fürth lieber wären bitte auch melden!<br />
<br />
<headertabs /></div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_German_Chapter_Stammtisch_Initiative&diff=120636OWASP German Chapter Stammtisch Initiative2011-11-23T06:53:17Z<p>Kai Jendrian: </p>
<hr />
<div>== Was ist ein OWASP Stammtisch? ==<br />
<br />
Ein OWASP Stammtisch ist ein regelmäßiges Treffen von OWASP Interessierten in einem Restaurant oder einer Gaststätte. Es gibt zumeist kein festes Programm mit Vorträgen. Der Austausch von Ideen und Erfahrungen soll im Vordergrund stehen. In kleineren Gruppen reicht ein Laptop für Präsentationen, da zumeist keine technischen Möglichkeiten für Vorführungen vorhanden sind. <br />
<br />
Ein lokaler Verantworlicher lädt zum Stammtisch über die German Chapter Mailing Liste ein. Es gelten grundästzlich dieselben [http://www.owasp.org/index.php/Chapter_Rules Regeln wie bei Chapter Meetings]. <br />
<br />
Die lokalen OWASP Stammtische sollen Interessierten Gelegenheit zum Austausch und zum Knüpfen von Kontakten geben. Wenn Sie OWASP selbst kennen lernen wollen, dann besuchen Sie einen Stammtisch in Ihrer Nähe. Wenn es noch keinen gibt, dann gründen Sie einfach einen. <br />
<br />
== Stammtisch oder Chapter? ==<br />
<br />
Stammtische sind keine Konkurrenz für Chapter sondern eine willkommene Ergänzung. Sie ermöglichen regelmäßige Treffen im Rahmen der OWASP-Community ohne die organisatorischen Hürden für einen regulären Chapter-Betrieb. Erreicht ein Stammtisch die "kritische" Masse für einen Chapter-Betrieb, dann ist eine Aufwertung in eine lokale Chapter-Gründung ebenfalls höchst willkommen. <br />
<br />
<br> <br />
<br />
== Lokale Stammtische ==<br />
<br />
==== München ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Münchner Stammtisch findet '''jeden dritten Dienstag im Monat um 19:00 Uhr '''im Restaurant und Biergarten '''"Cafe Waldfrieden"''' in der '''Fürstenrieder Str. 277''' in '''81377 München''' statt. <br> <br />
<br />
Es ist immer für 12 Personen reserviert, bei gutem Wetter (t &gt; 20,0 °C gefühlt, kein Niederschlag, Tageslicht) im Biergarten, bei schlechtem Wetter im Nebenraum - im Zweifelsfall bitte einfach am Tresen nach dem OWASP-Stammtisch fragen. Um vorhergehende '''Anmeldung per Mail bei [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] wird gebeten''', um ggf. weitere Ressourcen reservieren zu lassen - '''spontane "Zaungäste" sind aber jederzeit ebenso willkommen'''. <br />
<br />
===== Der 29. Münchner OWASP Stammtisch am 20.12.2011 =====<br />
<br />
Der Stammtisch im November entfällt leider Ersatzlos. Beschwert Euch bitte bei den Organisatoren des [https://www.owasp.org/index.php/German_OWASP_Day_2011 4. OWASP Day Germany], am besten direkt vor Ort in München während der sicherlich tollen Veranstaltung :-)<br />
<p><br />
Voraussichtliches Dezember-Thema: Die Web Application Security im besonderen Spannungsfeld zwischen Spekulatius und Glühwein unter Berücksichtigung noch zu verbrennender Endjahres-IT-Budgets.<br />
<br />
===== Um 19:00 im <i>"Cafe Waldfrieden"</i> ===== <br />
Cafe Waldfrieden<br><br />
Fürstenrieder Str. 277<br><br />
81377 München<br><br />
<br />
Telefon: (089) 7244 1429<br><br />
<br />
Das Cafe befindet sich direkt gegenüber des Haupteingangs des Waldfriedhofs.<br><br />
<br />
Öffentlicher Nahverkehr: <br />
U-Bahn <b>U6</b>, Haltestelle <b>Holzapfelkreuth</b><br />
oder <b>Stadtbus 151</b>, Haltestelle <b>Waldfriedhof</b> <br />
<br />
Nützliche Links: [http://maps.google.com/maps/place?cid=6980435847828545857 Google Maps, "Places"] oder [http://maps.google.com/maps?q=Fürstenrieder+Straße+277%2C+münchen&btnG=Maps-Suche Google Maps, direkte Adresse] und [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen].<br />
<!--<br />
Georg-Zech-Allee 15<br> 80995 München<br> Tel.: 089 - 31 47 663<br> <br />
<br />
[http://www.schlemmerregion-muenchen.de/rp_restaurant_kurzinfo.afp?!_2RJ1E8VY3&bl=D00&rid=_0S50REUPA&rve=5701B98n Info],[http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=+Georg-Zech-Allee+15,+m%C3%BCnchen&sll=48.140232,11.545644&sspn=0.006801,0.018775&ie=UTF8&ll=48.209117,11.531417&spn=0.006792,0.018775&z=16&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br> <br />
<br />
Gasthaus Löwe und Raute<br> Nymphenburger Str. 64<br> 80335 München<br> Tel. 089 / 130 143 97<br> <br />
<br />
[http://www.loeweundraute.com Homepage], [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=Nymphenburger+Str.+64,+m%C3%BCnchen&sll=53.87844,6.152344&sspn=10.478551,38.012695&ie=UTF8&ll=48.152373,11.548777&spn=0.011567,0.037122&z=15&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br />
--><br />
<br />
===== Geplante Stammtisch-Vorträge =====<br />
<br />
Denkbare Vortrags-Themen an einem der zukünftigen Stammtische: <br />
<br />
*Dein Thema hier! :-)<br />
<br />
Sobald wir eine konkrete Zusage haben, werde ich das bei der Ankündigung des jeweiligen Termins mit bekannt geben.<br> <br />
<br />
Also, wie immer: Ich bitte um kurze Info an mich, ob jemand noch weitere (für uns relevante) Themen parat hat, die er uns näher bringen möchte. ''Verkaufsveranstalter werden alle 20 Minuten ausgebuht und müssen dann eine (neue) Runde Bier bezahlen.''<br><br />
<br />
===== Bereits gehaltene Stammtisch-Vorträge =====<br />
<br />
*Juni 2011: Rückblick und Würdigung der [https://www.owasp.org/index.php/AppSecEU2011 OWASP AppSec Europe 2011 in Dublin] (Andreas von Keviczky)<br />
*Februar 2011: Nachklapp zum [http://www.owasp.org/index.php/Summit_2011/Summit_Results_Summary OWASP Summit 2011 in Portugal] (Achim Hoffmann und Ralf Reinhardt) <br />
*Januar 2011: Offene Diskussion über die Sicherheit von mobilen Endgeräten bei Einsatz im Firmennetz und 'in the wild' (Matthias Trojahn)<br />
*November 2010: Vektorbasierte Anomalien-Erkennung in HTTP-Traffic (Michael Kirchner), [http://students.fh-hagenberg.at/sec/s0810304003/Thesis_Anomalieerkennung_in_HTTP-Daten_Vortrag_OWASP.pdf Folien].<br />
*Juni 2010: Aus der Werkzeug-Schatzkiste des gehobenen Pentesters (Uli Petersen und Achim Hoffmann), u.a. wurde [http://www.owasp.org/index.php/Category:OWASP_EnDe "EnDe"] besprochen.<br />
*März 2010: ISO/IEC 27001 (Barbara Schachner und Feiliang Wu)<br />
*November 2009: Was eine WAF (nicht) kann ([https://mirko.dziadzka.de/ Mirko Dziadzka]), [https://mirko.dziadzka.de/Vortrag/owasp-waf-20091124.pdf Folien]. <br />
*Oktober 2009: Eine Kurzeinführung in Injection-Angriffe (Ralf Reinhardt)<br />
<br />
===== Spread the word =====<br />
<br />
Wie immer möchte ich jeden bitten, der Menschen kennt, von denen er sich vorstellen könnte, dass Sie kommen möchten und könnten, diese Einladung an eben diese Menschen weiter zu leiten.<br> <br />
<br />
Thema und hinreichende Bedingung ist in erster Linie Web Application Security. Man muss überhaupt nichts von OWASP wissen, ein vorhergehender Blick auf die Website indes schadet sicher nicht.<br> <br />
<br />
Schönen Gruß, [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] <br />
<br />
==== Frankfurt ====<br />
<br />
===== Mitorganisator für den Frankfurter Stammtisch gesucht =====<br />
OWASP ist eine aktive Community und zusammen geht alles besser. Damit der Stammtisch regelmäßig stattffinden kann und für die Teilnehmer Planungssicherheit herrscht möchte ich gerne eine Co-Moderatorin oder einen Co-Moderator für die Organisation hinzugewinnen. Das Treffen soll nich gleich ausfallen, wenn der Organisator kurzfristig verhindert ist. Der Arbeitsaufwand ist sehr überschaubar. Eine [https://www.owasp.org/index.php/Membership Mitgliedschaft] bei OWASP ist nicht erforderlich, aber natürlich erwünscht :-) Dann gibt es auch eine "foo.bar@owasp.org" Emailadresse, ein T-Shirt und ein gutes Gefühl. Wer sich dafür interessiert, möge sich bitte bei [mailto:boris@owasp.org Boris Hemkemeier] melden oder direkt auf die [https://www.owasp.org/index.php/Membership Membership Seite] gehen.<br />
===== Allgemeines =====<br />
<br />
Ähnlich wie in München soll der Stammtisch hauptsächlich zum lockeren Austausch und Netzwerken dienen. <br />
<br />
Eingeladen sind alle Interessierten an <br />
<br />
*Application Security <br />
*Web Application Security <br />
*Secure Software Lifecycle <br />
*Security-Awareness Programme für Entwickler, Tester, Architekten und Auftraggeber <br />
*Security Management von Anwendungen im Unternehmen <br />
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten <br />
*Anwendungssicherheit und Metriken <br />
*und natürlich an OWASP selbst.<br />
<br />
Es soll keine Hardcore Hacker Veranstaltung sein. Viele werden mit IT-Security konfrontiert und suchen Lösungen für sichere Anwendungen. Technische Themen sind natürlich auch erwünscht. Dafür können wir eigenen Termine auf dem Stammtisch planen.<br />
<br />
===== Der 4. Frankfurter OWASP Stammtisch findet am 23.11.2011 statt =====<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 23.11.2011. Für das folgende Treffen ist der 25.01.2012 geplant.<br />
<br />
ACHTUNG: Der 4. OWASP Stammtisch Frankfurt wird im [http://www.depot1899.de/ Depot 1899] in der [http://j.mp/uHFH9X Textorstraße 33, 60594 Frankfurt am Main] stattfinden. Wir testen gerade Lokale aus in denen man vielleicht auch einmal einen Vortrag halten kann mit anschließender Diskussion.<br />
<br />
Bei diesem Treffen stehen nebem dem Kennenlernen die letzen OWASP Konferenzen im Vordergrund. Wir werden einen Bericht vom German OWASP Day am 17.11.2011 haben und eventuell auch einen von der OWASP AppSec US: Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/inu2mt2sngx7dzs4 Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
===== Der 3. Frankfurter OWASP Stammtisch findet am 21.09.2011 statt =====<br />
<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 21.09.2011. Für das folgende Treffen ist der 23.11.2011 geplant.<br />
<br />
Der 3. OWASP Stammtisch Frankfurt wird wieder in der [http://j.mp/piQdaP Arche Nova, Kasseler Str. 1a, Frankfurt a.M.] stattfinden. <br />
<br />
Bei diesem Treffen steht wieder das Kennenlernen im Vordergrund. Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/77m7p3qama2u723z Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
==== Stuttgart ====<br />
<br />
===== Der Stammtisch findet jeden ersten Montag jeden zweiten Monat statt. =====<br />
<br />
Wir treffen uns jeweils um 19 Uhr im [http://www.sportpark-neuwirtshaus.de/ Sportrestaurant Neuwirtshaus], Neuwirtshausstrasse 199a 70439 Stuttgart. Wer mit dem ÖPNV anreist (S-Bahn Haltestelle Porsche) kann sich per E-Mail mit der Ankunftszeit melden, es gibt dann einen Fahrdienst &nbsp;:) <br />
<br />
Derzeit sind wir insgesamt rund 10 Personen und freuen uns auf weitere Teilnehmer. Zu jedem Termin wird ein Vortrag zum Besten gegeben, Wünsche jederzeit gerne. Um vorhergehende Anmeldung per [mailto:tobias.glemser@owasp.org E-Mail] wird gebeten, wer das verschwitzt darf aber natürlich auch kommen. Bei Fragen zum Stammtisch einfach kurz anschreiben. <br />
<br />
Der Stammtisch wird hier, über die OWASP-Germany Mailingliste und [https://www.xing.com/profile/Tobias_Glemser Xing] (einfach mit mir verknüpfen) angekündigt. <br />
<br />
Wir freuen uns auf Euer Kommen! <br />
<br />
Tobias <br />
<br />
'''Termine:''' <br />
<br />
*'''Termin Oktober fällt aufgrund it-sa aus, Anfang November wegen OWASP Day Germany'''<br />
<br />
*'''21.11.11''' <br />
<br />
:Programm: <br />
:*19.00h Beginn <br />
:*19.30h - t.b.a.<br />
<br />
----<br />
<br />
'''Rückblick '''<br> <br />
*01.08.2011. 10. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Vortrag "Neuerungen in Burp Pro 1.4", Michael Schäfer (Schutzwerk GmbH). Bilder von der Riesenjubiläumsparty im Anschluss müssen leider unter Verschluss gehalten werden. "What happens at Stammtisch, stays at Stammtisch". Achja: Grüße an die Vegas-Reisenden unter uns, die deswegen die Sause verpasst haben :)<br />
*06.06.2011. 9. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzfristige Absagen (unter anderem des Referenten) taten der Stimmung keinen Abbruch. Sehr interessante Diskussionen über Passwortsicherheit, RSA Token Security und anderes.<br />
*04.04.2011. 8. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Der bestbesuchteste Stuttgarter Stammtisch bisher. Die insgesamt 13 Teilnehmer diskutierten über den Vortrag von [http://webuser.hs-furtwangen.de/~doelitz/index.html Frank Dölitzscher] (Hochschule Furtwangen) zu einem Cloud-Frontend mit Single-Sign-On Anbindung und SSH-Key Erstellung [[File:2011-04-04_CloudIA_WebGUI_OWASP_Stammtisch_Stuttgart.pdf|Folien]] interessiert zu. Insbesondere wurden mögliche Schwachstellen der Implementierung der Lösung und des Java-Client zur SSH-Key Erstellung besprochen. Für beide Seiten ein Gewinn :)<br />
<br />
:Antworten von Frank bzgl. der offenen Fragen:<br />
:"- In der Version des Shibb-Idp den wir verwenden ist ein zwingender Restart beim Einlesen einer neuen Config notwendig. Die Konfiguration ist dateibasiert und gliedert sich in 3 Dateien:<br />
<br />
:a) Relying Party - regelt Förderation (Verweis auf MetaData)<br />
:b) MeTaData - Beinhaltet alle SPs mit Links darauf, Metadaten der einzelnen SP<br />
:c) AttributeFilter.xml - Regelt welche Userattribute werden einem SP nach erfolgreicher Autorisierung übermittelt<br />
<br />
:Die kritische Datei ist die AttributeFilter.xml.<br />
:In der aktuellsten Shibboleth Version sollte ein einfacher Reload der Konfigurationen auch prinzipiell möglich sein. Allerdings warnen die Entwickler vor einem Produktiveinsatz: "Caution Do NOT enable configuration reloading in a production environment unless you have a rigorous configuration testing process in place and used."<br />
<br />
: Siehe: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig<br />
<br />
:Unser aktueller Idp wurde inzwischen auf einen größeren Server umgezogen. Ein Restart dauert nun etwa 25 Sekunden. Das ist zwar deutlich schneller als zuvor (1,5min) allerdings für das Cloud-Szenario immer noch nicht praktikabel.<br />
<br />
:Zur Erreichbarkeit der VMs untereinander: Die VMs akzeptieren nur Incoming Traffic vom Reverse-Proxy (SP)."<br />
<br />
:[[Image:2011-04-04-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*07.02.2011. 7. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzdiskussion: "Brauchen wir ein Security-Framework Verwaltungs-Protokoll?"<br />
<br />
*08.11.2010. 6. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Nanu, wieder kein Vortag, aber beschwert hat sich auch niemand :)<br />
<br />
*06.09.2010. 5. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Leider kein Vortrag, aber eine launige Runde. Wer schon immer wissen wollte was Globolis, Pferde und die Goonies mit IT-Security zu tun haben oder wie die Visitenkarte von Kevin Mitnick aussieht, der ist bei uns einfach genau richtig..<br />
<br />
*07.06.2010. 4. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:Neuigkeiten vom Chapter Meeting im Mai 2010 <br />
:Vorstellung und Erfahrungsberichte mit den kommerziellen Tools HP Webinspect (Andy Kurtz) und Acunetix (Tobias Glemser). Keine Folien da "Freestyle". Kurzfazit war: Beide Tools bilden ein ähnliches Featureset ab, um manuelles Testen kommt man niemals rum.<br />
<br />
:[[Image:2010-06-07-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*12.04.2010. 3. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:[[Media:OWASP_Stammtisch_20100412.ppt|Vortrag "WATOBO - Web Application Toolbox"]] von Andreas Schmidt. Vorstellung eines selbst entwickeltes Werkzeugs ([http://watobo.sf.net WATOBO - Web Application Toolbox]) zur Überpruefung von Webapplikationen. Das Tool selbst ist unter der GNU Public License veröffentlicht und soll Sicherheitsspezialisten bei der Durchführung von semi-automatisierten Sicherheitsanalysen unterstützen.<br />
<br />
*01.02.2010. 2. OWASP German Chapter Stammtisch Stuttgart<br />
<br />
:Vortrag Vorstellung OWASP Whitepaper von Tobias Glemser "[[Best Practice: Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]"<br><br />
<br />
*30.11.2009. 1. OWASP German Chapter Stammtisch Stuttgart<br><br />
<br />
:Das erste Treffen diente dem Beschnuppern und gemeinsamen Pläne schmieden für die nächsten Male<br><br />
<br />
<br> <br />
<br />
==== Düsseldorf ====<br />
<br />
===== Coming soon! =====<br />
<br />
Vorgeschlagen von: Sven Schlüter <br> //TODO <br />
<br />
==== Köln ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Kölner Stammtisch trifft sich zur Zeit alle zwei Monate. Es ist geplant zwischen Vorträgen und lockeren Diskussionen zu alternieren. Jeder ist herzlich willkommen und kann gerne noch Freunde, Kollegen, Interessierte mitbringen. <br />
<br />
<br> <br />
<br />
===== 8. Kölner OWASP Stammtisch am 27.10.2011 =====<br />
<br />
Wir treffen uns zum achten Kölner Stammtisch am 27.10.2011 um '''19:00Uhr'''. <br />
<br />
Diesmal wieder im [http://www.haus-toeller.de/ Brauhaus Töller] in der Weyerstraße.<br />
<br />
Bitte gebt mir noch eine [mailto:ralf.allar@owasp.org Rückmeldung], falls ihr kommt, damit ich einen Überblick über die Zahl der Anwesenden erhalte. Danke! <br />
<br />
<br />
==== Hamburg ====<br />
<br />
<br />
===== Generelles =====<br />
<br />
Wer und Interesse hat mitzuwirken oder mitgestalten möchte, bitte bei Dirk Wetter melden (dirk punkt wetter aet owasp punkt org). Besonders Vorträge plus Vortragende sind gefragt. Ansonsten werden die Treffen natürlich über die [https://lists.owasp.org/mailman/listinfo/owasp-germany/ OWASP-Deutschland-Liste] angekündigt. <br />
<br />
===== Fünftes Treffen am 13.9.2011 =====<br />
<br />
* Uhrzeit: 20 Uhr<br />
* Vortrag von Dirk Kollberg (Sophos)/Toralv Dirro (McAfee) "Sicherheits-Ratatouille: Eine bunte Mischung mit Zutaten aus Sozialen Netzen, neues aus der Welt der Online-Banking-Trojaner und vieles mehr"<br />
* Ort: Lehmanns Fachbuchhandlung, Kurze Mühren 6 (.i.d. Nähe des Hbf)<br />
* [https://lists.owasp.org/pipermail/owasp-germany/2011-August/000303.html Abstract] von der Mailingliste<br />
<br />
===== Viertes Treffen am 14.4.2011 =====<br />
<br />
* Vortrag von Tim Sattler: "Sicherheit in der Cloud - Chancen und Risiken". <br ><br />
* Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
* [http://www.guug.de/lokal/hamburg/talks/OWASP_Sicherheit_in_der_Cloud.pdf Slides]<br />
<br />
===== Drittes Treffen am 7.3.2011 =====<br />
<br />
Den Rosenmontag begehen wir im Norden mit einem Konkurrenzprogramm: Gemütlicher OWASP-Abend mit sinnieren über die Websicherheit in <i>Omas Apotheke</i> in der Schanze. Los geht's um 19 Uhr. <br />
<br />
===== Zweites Treffen inkl. Vortrag am 14.10.2010 =====<br />
<br />
VortragsthemaÖ "OWASP Top 10 - Wat nu?" <br />
[http://drwetter.eu/talks/OWASP_T10-Wat-nu.pdf Slides]<br><br />
Datum/Zeit: 14.10.2010, 19 Uhr<br><br />
Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
Vortragender: Dirk Wetter<br><br><br />
<br />
===== Erstes Treffen am 8.7.2010 =====<br />
<br />
Wir treffen uns erstmalig am '''8.7.2010 um 19 Uhr''' auf [http://maps.google.de/maps?q=strandpauli&um=1&ie=UTF-8&sa=N&hl=en&tab=wl Strandpauli], einem der Beachclubs mit Aussicht auf den schönen Hamburger Hafen. Der 8.7. ist der erste Ferientag in HH und fußballfrei. <br> Inhalt des ersten Treffens ist eher ein Informationsaustausch: Neben etwas Networking wäre es prima, Erwartungen zu diskutieren und vielleicht die ersten Vorträge zu planen. Da das in dem Etablissement im Sommer dort wahrscheinlich nicht ganz leer sein wird und der Beachclub sicherlich nicht auf den OWASP-Stammtisch wartet&nbsp;;-) wird wärmstens empfohlen, bis zum 7.7. morgens Dirk Wetter sich anzumelden, der dann die Reservierung vornimmt. Sonst muss man halt stehen.&nbsp;;-) <br />
<br> <br />
Mindestens einer wird ein OWASP-T-Shirt tragen. (Hint: Das Logo ist auch auf dieser Webseite zu finden).<br />
<br />
==== Karlsruhe ====<br />
<br />
===== 5. Glühweintrinken für die Sicherheit am 1[235].12.2011 =====<br />
<br />
Zum Jahresabschluss soll noch ein letzter OWASP-Stammtisch in Karlsruhe stattfinden, auf dem wir über das letzte Jahr OWASP in Karlsruhe und allgemein reflektieren und philosophieren können. Es wäre schön, wenn wir mit den Erfahrungen dieses Jahres uns für das nächste Jahr etwas orientieren können. Weiterhin können wir auf einen erfolgreichen OWASP-Day zurückblicken und einen Kurzbericht über die Erfahrungen bei der Übersetzung der Top 10 geben.<br />
<br />
Um in der hektischen Vorweihnachtszeit möglichst viele Teilnehmer zu gewinnen, steht der Termin noch nicht genau fest, sondern soll über Doodle ermittelt werden: http://www.doodle.com/we5eqvx3eq3c7fnm<br />
<br />
Treffpunkt wird an dem gewählten Terminum 19:00 Uhr an der Pyramide am Marktplatz in KA sein. Je nach Wetter und Laune können wir dann das Treffen in eine der umliegenden Lokalitäten verlagern...<br />
<br />
<br />
===== 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
==== Nürnberg ====<br />
<br />
===== Zweiter Stammtisch =====<br />
<br />
Ein zweiter Stammtisch für den Raum Nürnberg, Fürth und Erlangen soll November oder Dezember stattfinden!<br />
<br />
Termin: möglichst noch im Dezember, sonst Anfang 2012<br />
<br />
Ort: Gaststätte in der Nürnberger Innenstadt<br />
<br />
===== Organisatorisches =====<br />
<br />
Bei Interesse bitte bei [mailto:heiko.richler@owasp.org Heiko Richler] melden. Willkommen ist jeder! Wer nur dieses mal nicht kann oder wem Erlangen oder Fürth lieber wären bitte auch melden!<br />
<br />
<headertabs /></div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=File:OWASPTop10_2010_DE_Version_1_0.pdf&diff=120443File:OWASPTop10 2010 DE Version 1 0.pdf2011-11-18T21:59:54Z<p>Kai Jendrian: uploaded a new version of &quot;File:OWASPTop10 DE Version 1 0.pdf&quot;: Fixed some links within the document</p>
<hr />
<div>German Translation of OWASP Top 10 2010</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=File:OWASPTop10_2010_DE_Version_1_0.pdf&diff=120258File:OWASPTop10 2010 DE Version 1 0.pdf2011-11-16T09:30:32Z<p>Kai Jendrian: uploaded a new version of &quot;File:OWASPTop10 DE Version 1 0.pdf&quot;: Correction of file content. Removed duplicate page.</p>
<hr />
<div>German Translation of OWASP Top 10 2010</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_German_Language_Project&diff=120257OWASP German Language Project2011-11-16T09:26:59Z<p>Kai Jendrian: </p>
<hr />
<div>==== Main ====<br />
'''Welcome to the German Language Project'''<br />
<br />
The German Language Project is a new OWASP Project that will provide a foundation, guideance and common terminology for German translations (as well as other German language specific activities) of OWASP documents and parts of the OWASP web site. Furthermore, it will organize, plan and priorize new language projects such as translations.<br />
<br />
We will trying to align our activities with the [[OWASP_Internationalization | OWASP Internationalization]] project as well as with similar activities such as the [http://www.owasp.org/index.php/OWASP_Spanish Spanish Project] or the [http://www.owasp.org/index.php/Projects/OWASP_Portuguese_Language_Project Portuguese Language Project].<br />
<br />
== News ==<br />
'''November 16, 2011. Finished translation of OWASP Top 10. Any comments to [mailto:top10@owasp.de top10@owasp.de]<br />
'''July 9, 2011. Meeting on German Translation of OWASP Top Ten in Karlsruhe''' (please contact [mailto:kai.jendrian@owasp.org kai.jendrian@owasp.org] if you want to participate). <br/><br />
'''March 16, 2011. German Language Project has been officially started.'''<br />
<br />
== Participation == <br />
If you wish to contribute in the project please join us at [https://lists.owasp.org/mailman/listinfo/owasp-german-language-project mailing list subscription page]. <br />
<br />
'''Follow and participate at our [http://www.owasp.org/index.php/Talk:OWASP_German_Language_Project discussions]''' (German)<br />
<br />
== Deliverables ==<br />
Click on the link on each issue to go to the specific resource (translated into German).<br />
<br />
* German translations of all the release-level document projects:<br />
** '''OWASP ASVS''' - Ver 1.0 ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word]) by Matthias Rohr<br />
** '''OWASP Top 10 2010''' - ([https://www.owasp.org/index.php/File:OWASPTop10_DE_Version_1_0.pdf PDF])<br />
* German translations of major sections of OWASP web site:<br />
** nothing yet<br />
* German translations of OWASP software<br />
** nothing yet<br />
<br />
== Roles ==<br />
We are basically following the roles sugestet by the [[OWASP_Internationalization | OWASP Internationalization]] .<br />
<br />
The proposed skills are: <br />
<br />
*'''Translator(s)''' <br />
**Basic computer related knowledge. <br />
**Good English skills <br />
**Fluent in German language <br />
**Working knowledge in application security skills <br />
*'''Editor(s)''' <br />
**Strong computer related knowledge <br />
**Strong English skills <br />
**Strong skills in German language, participation in translation project of other open source projects is a plus. <br />
**Strong knowledge in application security skills <br />
*'''Translation leader.''' Person in charge of coordinate the translation effort. There are no special requirements, just the ability to manage a team of people and deliver on proposed time.<br />
<br />
== Current Translation Projects ==<br />
<br />
{| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;"<br />
|-<br />
! style="border-left: 1px solid black;" | Project<br />
! Version<br />
! Status<br />
! Translation Leader<br />
! Translation Team<br />
! Editor Team (QA)<br />
! (Expected) Completion Date<br />
! Help needed?<br />
! Project Site<br />
|-<br />
| [http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project OWASP Top 10]<br />
| 2010<br />
| Done<br />
| Kai Jendrian<br />
| Frank Dölitzscher, Tobias Glemser, Dr. Ingo Hanke, Kai Jendrian, Ralf Reinhard, Michael Schäfer<br />
| Frank Dölitzscher, Tobias Glemser, Dr. Ingo Hanke, Kai Jendrian, Ralf Reinhard, Michael Schäfer<br />
| November 16, 2011<br />
| <br />
|([https://www.owasp.org/index.php/File:OWASPTop10_DE_Version_1_0.pdf PDF])<br />
|-<br />
| [http://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project OWASP ASVS]<br />
| 1.0<br />
| Done<br />
| Matthias Rohr<br />
| Matthias Rohr<br />
| Olaf Schulz<br />
| October 10, 2010<br />
| Review<br />
| ([http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.pdf PDF], [http://owasp-asvs.googlecode.com/svn/trunk/documentation/asvs-webapp-release-2009-de.doc Word])<br />
|}<br />
<br />
== Other OWASP Projects in German Language ==<br />
* [[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls]]<br />
* [[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]] <br />
<br />
== Ideas ==<br />
<br />
{| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;"<br />
|-<br />
! style="border-left: 1px solid black;" | Idea<br />
! Translation Leader<br />
! Translation / Editor Team<br />
! Help needed (e.g. Translators, Editors)<br />
! Comment (e.g. why this project should be translated?)<br />
|-<br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
|-<br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
| <tbd><br />
|}<br />
<br />
== Out of Scope ==<br />
Translations of the following sections are NOT in scope<br />
* Local Chapters Pages<br />
* Presentations<br />
* Conferences<br />
* Videos<br />
* Blogs<br />
* All the projects deliverables in Alpha and Beta Stages<br />
* All the documentation “on development” like Guide Version 3.0<br />
* Translation of pages, documentation or tools to other language other than German according to the stated in above section.<br />
<br />
<br />
<br />
<br />
==== Glossary ====<br />
The following lists contains accepted German translations for English terms that are directly or indirectly related to application security. Many of them are already used in existing OWASP translations and should therefore not be changed without further discussion. German terms that are not used in the field are not included in this list.<br />
<br />
Some English terms are widely used and accepted in German too and can (or should) therefore be used instead of a possible German translation.<br />
<br />
The order used in the "German / Translation" section represents the proposed usage.<br />
<br />
'''Please do not change any existing definition without discussing it on the mailing list!'''<br />
<br />
{| cellspacing="0" cellpadding="3" border="1" style="border: 1px solid black;"<br />
|-<br />
! style="border-left: 1px solid black;" | English<br />
! German Translation / Deutsche Übersetzung<br />
! German Description<br />
! Comment / Kommentar<br />
|-<br />
| Access Control<br />
| Access Control, Zugriffskontrolle<br />
| <br />
|<br />
|-<br />
| Accountability<br />
| Verbindlichkeit<br />
| <br />
|<br />
|-<br />
| Application Security<br />
| Anwendungssicherheit<br />
|<br />
| <br />
|-<br />
| Attack<br />
| Angriff<br />
|<br />
| <br />
|-<br />
| Authentication<br />
| Authentisierung<br />
|Im Deutschen unterscheiden man gelegentlich, im Gegensatz zum Englischen, zwischen ''Authentifizierung'' und ''Authentisierung''<br />
| siehe auch: [http://de.wikipedia.org/wiki/Authentifizierung]<br />
|-<br />
| Awareness<br />
| Awareness, Bewusstsein<br />
|<br />
| <br />
|-<br />
| Backdoor<br />
| Backdoor, Hintertür<br />
|<br />
|<br />
|-<br />
| Checksum<br />
| Prüfsumme<br />
| <br />
| <br />
|-<br />
| Confidence<br />
| Vertrauen<br />
| <br />
|<br />
|-<br />
| Confidentiality<br />
| Vertraulichkeit<br />
|<br />
| <br />
|-<br />
| Countermeasure<br />
| Gegenmaßnahme<br />
|<br />
| <br />
|-<br />
| Coverage<br />
| Abdeckung<br />
| <br />
|<br />
|-<br />
| Cryptographic Module<br />
| Kryptographisches Modul<br />
|<br />
| <br />
|-<br />
| Design Verification<br />
| Designverifikation<br />
| <br />
|<br />
|-<br />
| Impact<br />
| Auswirkung (eines Angriffs oder Bedrohung)<br />
|<br />
| wörtlich: Anprall, Anschlag, Auswirkung<br />
|-<br />
| Input Validation<br />
| Eingabevalidierung<br />
|<br />
| <br />
|-<br />
| Internal Verification<br />
| Interne Verifikation<br />
|<br />
| <br />
|-<br />
| Logging<br />
| Logging, Protokollierung<br />
| <br />
| <br />
|-<br />
| Malware<br />
| Malware, Schadprogramm<br />
| <br />
|<br />
|-<br />
| Malicious Code<br />
| Schadcode<br />
| <br />
| <br />
|-<br />
| Measure<br />
| Maßnahme<br />
|<br />
| <br />
|-<br />
| Non Repudiation<br />
| Nichtabstreitbarkeit<br />
|<br />
| <br />
|-<br />
| Output Validation<br />
| Ausgabevalidierung<br />
|<br />
| <br />
|-<br />
| Protection Requirements<br />
| Schutzbedarf<br />
|<br />
| <br />
|-<br />
| Residual Risk<br />
| Restrisiko<br />
|<br />
| <br />
|-<br />
| Rigor<br />
| (Verifikations-)Strenge<br />
|<br />
|<br />
|-<br />
| Risk Analysis<br />
| Risikoanalyse<br />
|<br />
| <br />
|-<br />
| Safeguard<br />
| Schutzmechanismus<br />
|<br />
| <br />
|-<br />
| Security Configuration<br />
| Sicherheitskonfiguration<br />
|<br />
| <br />
|-<br />
| Security Control<br />
| Sicherheitsmechanismus, Security Control<br />
|<br />
| <br />
|-<br />
| Session<br />
| Session, Sitzung<br />
| <br />
| <br />
|-<br />
| Session Management<br />
| Session Management, Sitzungsverwaltung<br />
| <br />
| <br />
|-<br />
| Security Architectur<br />
| Sicherheitsarchitektur<br />
|<br />
| <br />
|-<br />
| Threat<br />
| Bedrohung<br />
|<br />
| <br />
|-<br />
| Threat Modeling<br />
| Bedrohungsmodellierung, Threat Modeling<br />
| <br />
|<br />
|-<br />
| Trojan Horse<br />
| Trojaner, Trojanische Pferd<br />
|<br />
| <br />
|-<br />
| Verification<br />
| Verifikation, Prüfung<br />
| <br />
|<br />
|-<br />
| Verification Requirement<br />
| Verifikationsanforderung, Prüfanforderung<br />
|<br />
|<br />
|-<br />
| Weakness<br />
| Schwachstelle<br />
| Fehler in einer Software, aus dem unter bestimmten Bedingungen eine Sicherheitslücke entstehen kann. <br />
| wörtlich: Schwäche<br />
|-<br />
| Vulnerability<br />
| Sicherheitslücke<br />
| Schwachstelle, die in der Software vorhanden ist und dazu benutzt werden kann, dass die Software unbeabsichtigt Daten verändert, den üblichen Ablauf unterbricht oder falsche Aktionen ausführt<br />
| wörtlich: Angreifbarkeit, Verwundbarkeit<br />
|}<br />
<br />
For the following terms, there is no German translation which is widely used or accepted:<br />
<br />
*'''Blacklist'''<br />
*'''Denial-of-Service'''<br />
*'''Easter Egg'''<br />
*'''Encoding'''<br />
*'''Escaping'''<br />
*'''Target of Verification (TOV)'''<br />
*'''Whitelist'''<br />
<br />
==== Roadmap ====<br />
The project's overall goal is to...<br />
<br />
'''provide a foundation, guideance and common terminology for German translations of OWASP documents and parts of the OWASP web site as well as other activities related to the German language. Furthermore, it will organize, plan and priorize new language projects such as translations.'''<br />
<br />
In the near term, we are focused on the following tactical goals...<br />
<br />
1. Link all existing German OWASP translation to this page<br />
<br />
2. Setting-up a consistent glossary for german application security terms<br />
<br />
3. Priorize and organize future translations and actions<br />
<br />
4. Provide Translation Guidelines<br />
<br />
5. Provide Translation Templates<br />
<br />
<br />
<br />
==== Related Resources ====<br />
<tbd><br />
<br />
==== Project About ====<br />
{{:Projects/OWASP German Language Project | Project About}}<br />
<br />
__NOTOC__ <headertabs /><br />
<br />
<br />
[[Category:OWASP_Document]] <br />
[[Category:OWASP_Alpha_Quality_Document]] <br />
[[Category:OWASP_Project|German Language Project]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Category:OWASP_Top_Ten_Project&diff=120256Category:OWASP Top Ten Project2011-11-16T09:16:32Z<p>Kai Jendrian: </p>
<hr />
<div>{{OWASP Book|1400974}} <br />
<center><br>'''Do You Recommend the OWASP TOP 10?''' Tweet a sign of support [http://twitter.com/home/?status=OWASP+has+FREE+practical+software+development+and+security+resources:+http://bit.ly/bMb0SM Click Here] </center><br />
<br><br />
<br />
==== Main ====<br />
<br />
'''Welcome to the OWASP Top Ten Project''' - if your looking for the OWASP Top 10 Mobile - [http://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab=Top_Ten_Mobile_Risks Click Here]<br />
<br />
== OWASP Top 10 for 2010 ==<br />
<br />
On April 19, 2010 we released the final version of the OWASP Top 10 for 2010, and here is the associated [[OWASPTop10-2010-PressRelease|press release]]. This version was updated based on numerous comments received during the comment period after the release candidate was released in Nov. 2009. <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf OWASP Top 10 - 2010 Document] <br />
*[[Top 10 2010|OWASP Top 10 - 2010 - wiki]] <br />
*[http://owasptop10.googlecode.com/files/OWASP_Top_10_-_2010%20Presentation.pptx OWASP Top 10 - 2010 Presentation]<br />
*[http://blip.tv/owasp-appsec-conference-in-europe/day2_track1_1430-1505-3936900 OWASP Top 10 Video of the Presentation above - this focused alot on the Top 10 for 2010 approach, rather than the details. (From OWASP AppSec EU 2010)]<br />
*[http://www.vimeo.com/9006276 OWASP Top 10 Video of this Presentation when the Top 10 for 2010 was 1st released for comment - this goes through each item in the Top 10. (From OWASP AppSec DC 2009)]<br />
<br />
The OWASP Top 10 Web Application Security Risks for 2010 are: <br />
<br />
*[[Top_10_2010-A1|A1: Injection]]<br />
*[[Top_10_2010-A2|A2: Cross-Site Scripting (XSS)]]<br />
*[[Top_10_2010-A3|A3: Broken Authentication and Session Management]]<br />
*[[Top_10_2010-A4|A4: Insecure Direct Object References]]<br />
*[[Top_10_2010-A5|A5: Cross-Site Request Forgery (CSRF)]]<br />
*[[Top_10_2010-A6|A6: Security Misconfiguration]]<br />
*[[Top_10_2010-A7|A7: Insecure Cryptographic Storage]]<br />
*[[Top_10_2010-A8|A8: Failure to Restrict URL Access]]<br />
*[[Top_10_2010-A9|A9: Insufficient Transport Layer Protection]]<br />
*[[Top_10_2010-A10|A10: Unvalidated Redirects and Forwards]]<br />
<br />
Please help us make sure every developer in the ENTIRE WORLD knows about the OWASP Top 10 by helping to spread the word!!! <br />
<br />
As you help us spread the word, please emphasize: <br />
<br />
*OWASP is reaching out to developers, not just the application security community <br />
*The Top 10 is about managing risk, not just avoiding vulnerabilities <br />
*To manage these risks, organizations need an application risk management program, not just awareness training, app testing, and remediation<br />
<br />
We need to encourage organizations to get off the penetrate and patch mentality. As Jeff Williams said in his 2009 OWASP AppSec DC Keynote: “we’ll never hack our way secure – it’s going to take a culture change” for organizations to properly address application security. <br />
<br />
If you are interested in doing a presentation on the OWASP Top 10, please feel free to use all or parts of this:<br />
<br />
== Introduction ==<br />
<br />
The OWASP Top Ten provides a powerful awareness document for web application security. The OWASP Top Ten represents a broad consensus about what the most critical web application security flaws are. Project members include a variety of security experts from around the world who have shared their expertise to produce this list. Versions of the 2007 were translated into English, French, Spanish, Japanese, Korean and Turkish and other languages. Translation efforts for the 2010 version are underway and they will be posted as they become available. <br />
<br />
We urge all companies to adopt this awareness document within their organization and start the process of ensuring that their web applications do not contain these flaws. Adopting the OWASP Top Ten is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code. <br />
<br />
== Versions ==<br />
<br />
Stable: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf OWASP Top 10 2010 - PDF] <br />
*[[Top 10 2010|OWASP Top 10 2010 - wiki]]<br />
<br />
2010 Translations: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20French.pdf OWASP Top 10 2010 - French PDF] <br />
*[https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf OWASP Top 10 2010 - German PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Indonesian.pdf OWASP Top 10 2010 - Indonesian PDF]<br />
*[http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf OWASP Top 10 2010 - Italian PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Japanese-A4.pdf OWASP Top 10 2010 - Japanese PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Korean.pdf OWASP Top 10 2010 - Korean PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf OWASP Top 10 2010 - Spanish PDF]<br />
*[http://www.owasp.org/images/a/a9/OWASP_Top_10_2010_Chinese_V1.0_Released.pdf OWASP Top 10 2010 - Chinese PDF]<br />
*[http://owasptop10.googlecode.com/files/OWASPTop%2010%20-%202010%20Vietnamese.pdf OWASP Top 10 2010 - Vietnamese PDF]<br />
<br />
<br />
2010 Release Candidate: <br />
<br />
*[http://www.owasp.org/index.php/File:OWASP_T10_-_2010_rc1.pdf OWASP Top 10 2010 Release Candidate] <br />
*[http://www.owasp.org/images/e/e1/OWASP_Top_10_RC-Public_Comments.docx OWASP Top 10 2010 Release Candidate Comments], except for one set of scanned comments [http://www.owasp.org/images/2/2e/OWASP_T10_-_2010_rc1_cmts_Kai_Jendrian.pdf which are here].<br />
<br />
Old versions: <br />
<br />
*[http://www.owasp.org/images/e/e8/OWASP_Top_10_2007.pdf OWASP Top 10 2007 - PDF] <br />
*[[Top 10 2007|OWASP Top 10 2007 - wiki]] <br />
*[http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#tab=Project_Details OWASP Top 10 2007 - PDF Translations are here] <br />
*[[Top 10 2004|OWASP Top 10 2004 - wiki]]<br />
<br />
== Users and Adopters ==<br />
<br />
The U.S. Federal Trade Commission strongly recommends that all companies use the OWASP Top Ten and ensure that their partners do the same. In addition, the U.S. Defense Information Systems Agency (DISA) has listed the OWASP Top Ten as key best practices that should be used as part of the DoD Information Assurance Certification and Accreditation Process ([http://iase.disa.mil/diacap/ DIACAP]). <br />
<br />
In the commercial market, the [http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf Payment Card Industry (PCI) standard] has adopted the OWASP Top Ten, and requires (among other things) that all merchants get a security code review for all their custom code. In addition, a broad range of companies and agencies around the globe are also using the OWASP Top Ten, including: <br />
<br />
*A.G. Edwards <br />
*Bank of Newport <br />
*Best Software <br />
*British Telecom <br />
*Bureau of Alcohol, Tobacco, and Firearms (ATF) <br />
*Citibank <br />
*Cboss Internet <br />
*Cognizant <br />
*Contra Costa County, CA <br />
*Corillian Corporation <br />
*Digital Payment Technologies <br />
*Foundstone Strategic Security <br />
*HP <br />
*IBM Global Services <br />
*National Australia Bank <br />
*Norfolk Southern <br />
*OneSAS.com <br />
*Online Business Systems <br />
*Predictive Systems <br />
*Price Waterhouse Coopers <br />
*Recreational Equipment, Inc. (REI) <br />
*SSP Solutions <br />
*Samsung SDS (Korea) <br />
*Sempra Energy <br />
*Sprint <br />
*Sun Microsystems <br />
*Swiss Federal Institute of Technology <br />
*Symantec <br />
*Texas Dept of Human Services <br />
*The Hartford <br />
*Zapatec <br />
*ZipForm <br />
*...and many others<br />
<br />
Several schools have also adopted the OWASP Top Ten as a part of their curriculum, including Michigan State University (MSU), and the University of California at San Diego (UCSD). <br />
<br />
Several open source projects have adopted the OWASP Top Ten as part of their security audits, including: <br />
<br />
*[http://plone.org Plone open source CMS project] (managed by the Plone Foundation)<br />
<br />
== Feedback ==<br />
<br />
Please let us know how your organization is using the Top Ten. Include your name, organization's name, and brief description of how you use the list. Thanks for supporting OWASP! <br />
<br />
We hope you find the information in the OWASP Top Ten useful. Please contribute back to the project by sending your comments, questions, and suggestions to topten@lists.owasp.org Thanks! <br />
<br />
To join the OWASP Top Ten mailing list or view the archives, please visit the [http://lists.owasp.org/mailman/listinfo/owasp-topten subscription page.] <br />
<br />
== Project Sponsors ==<br />
<br />
The OWASP Top Ten project is sponsored by [[Image:Aspect_logo.gif|link=http://www.aspectsecurity.com/]] [[Image:AppSecDC2009-Sponsor-softtek.gif|link=http://www.softtek.com]]<br />
<br />
<!-- ==== Project Identification ====<br />
{{Template:OWASP OWASP_Top10 Project}} --><br />
<br />
==== 2010 Translation Efforts ====<br />
<br />
Efforts are underway in numerous languages to translate the OWASP Top 10. If you are interested in helping, please contact the other members of the team for the language you are interested in contribution to, or if you don't see your language listed, please let me know you want to help and we'll form a volunteer group for your language too!! <br />
<br />
Completed Translations:<br />
<br />
*French: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20French.pdf OWASP Top 10 2010 - French PDF] ludovic.petit@owasp.org, sebastien.gioria@owasp.org, antonio.fontes@owasp.org, benoit.guerette@owasp.org, Jocelyn.aubert@owasp.org, Eric.Garreau@gemalto.com, Guillaume.Huysmans@gemalto.com <br />
*German: [https://www.owasp.org/images/b/b8/OWASPTop10_DE_Version_1_0.pdf OWASP Top 10 - German PDF] top10@owasp.de which is Frank Dölitzscher, Tobias Glemser, Dr. Ingo Hanke, [[User:Kai_Jendrian|Kai Jendrian]], [[User:Ralf_Reinhardt|Ralf Reinhardt]], Michael Schäfer<br />
*Indonesian: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Indonesian.pdf OWASP Top 10 2010 - Indonesian PDF] Tedi Heriyanto (coordinator), Lathifah Arief, Tri A Sundara, Zaki Akhmad<br />
*Italian: [http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf OWASP Top 10 2010 - Italian PDF] See Italian Translation Tab for Translation Team<br />
*Japanese: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Japanese-A4.pdf OWASP Top 10 2010 - Japanese PDF] cecil.su@owasp.org, Dr. Masayuki Hisada, Yoshimasa Kawamoto, Ryusuke Sakamoto, Keisuke Seki, Shin Umemoto, Takashi Arima<br />
*Korean: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Korean.pdf OWASP Top 10 2010 - Korean PDF] Hyungkeun Park, (mirrk1@gmail.com)<br />
*Spanish: [http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf OWASP Top 10 2010 - Spanish PDF] See Spanish Translation Tab for Translation Team<br />
*Chinese: [http://www.owasp.org/images/a/a9/OWASP_Top_10_2010_Chinese_V1.0_Released.pdf OWASP Top 10 2010 - Chinese PDF] See Chinese Translation Tab for Translation Team<br />
*Vietnamese: [http://owasptop10.googlecode.com/files/OWASPTop%2010%20-%202010%20Vietnamese.pdf OWASP Top 10 2010 - Vietnamese PDF] (NEW) Translation lead by Cecil Su - Translation Team: Dang Hoang Vu, Nguyen Ba Tien, Nguyen Tang Hung, Luong Dieu Phuong, Huynh Thien Tam<br />
<br />
Volunteer Translation Efforts Underway: <br />
<br />
*Portuguese: carlos.j.serrao@gmail.com; taquiles@gmail.com; wagner.elias@owasp.org; victoreufrasio@gmail.com; leo.cavallari@owasp.org; victoreufrasio@gmail.com; <br />
*Greek: Konstantinos Papapanagiotou (conpap@di.uoa.gr) <br />
*Turkish: bora@abi.com.tr <br />
*Malay: cecil.su@owasp.org <br />
*Czech: petr.zavodsky@owasp-czech-republic.cz<br />
*Dutch: marinus@kuivenhoven.com<br />
<br />
==== Project Details ====<br />
<br />
{{:GPC_Project_Details/OWASP_Top10 | OWASP Project Identification Tab}} <br />
<br />
==== Spanish Translation ====<br />
<br />
Me complace en informarles que gracias al trabajo excepcional y totalmente voluntario de las personas listadas abajo hemos concluido con la traducción del Top 10 al español. <br />
<br />
Muchas gracias a nuestro equipo de traducción! <br />
<br />
*Daniel Cabezas Molina <br />
*Edgar Sanchez <br />
*Juan Carlos Calderon <br />
*Jose Antonio Guasch <br />
*Paulo Coronado <br />
*Rodrigo Marcos <br />
*Vicente Aguilera<br />
<br />
El documento se puede obtener en la siguiente dirección URL: <br />
<br />
*[http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010%20Spanish.pdf Formato PDF] <br />
*[http://www.owasp.org/images/8/86/OWASP_Top_10_-_2010_FINAL_%28spanish%29.pptx Formato PPT]<br />
<br />
Desde ya, se agradecen los comentarios y/o sugerencias sobre el mismo. <br />
<br />
Saludos, <br />
<br />
Fabio Cerullo Comité Global de Educación OWASP <br />
<br />
==== Italian Translation ====<br />
<br />
Grazie al contributo del seguente team di traduttori, è possibile ottenere il documento OWASP Top 10 2010 in italiano: <br />
<br />
*Simone Onofri <br />
*Paolo Perego <br />
*Massimo Biagiotti <br />
*Edoardo Viscosi <br />
*Salvatore Fiorillo <br />
*Roberto Battistoni <br />
*Loredana Mancini <br />
*Michele Nesta <br />
*Paco Schiaffella <br />
*Lucilla Mancini <br />
*Gerardo Di Giacomo <br />
*Valentino Squilloni<br />
<br />
Il documento è disponibile [http://www.owasp.org/images/f/f9/OWASP_Top_10_-_2010_ITA.pdf qui.] <br><br />
<br />
Grazie e buona lettura! <br />
<br />
[http://www.owasp.org/index.php/Italy OWASP-Italy]<br />
<br />
==== Chinese Translation ====<br />
感谢以下为中文版本做出贡献的翻译人员和审核人员:<br />
<br />
* Rip Torn<br />
* 钟卫林<br />
* 高雯<br />
* 王颉<br />
* 于振东<br />
<br />
下载链接:<br />
<br />
点击[http://www.owasp.org/images/a/a9/OWASP_Top_10_2010_Chinese_V1.0_Released.pdf 这里下载PDF格式文档]<br />
<br />
其他相关链接:<br />
<br />
[http://www.owasp.org/index.php/China-Mainland OWASP China-Mainland]<br />
<br />
[http://www.owasp.org/index.php/OWASP_Chinese_Project OWASP Chinese Project]<br />
<br />
==== How Are Companies/Projects/Vendors Using the OWASP Top 10? ====<br />
<br />
Click the links for more details on each use! <br />
<br />
'''Warning''': these articles have not been rated for accuracy by OWASP. Product companies should be extremely careful about claiming to "cover" or "ensure compliance" with the OWASP Top 10. The current state-of-the-art for automated detection (scanners and static analysis) and prevention (waf) is nowhere near sufficient to claim adequate coverage of the issues in the Top 10. Nevertheless, using the Top 10 as a simple way to communicate security to end users is effective. <br />
<br />
;[http://blogs.msdn.com/b/sdl/archive/2008/05/01/sdl-and-the-owasp-top-ten.aspx Microsoft] <br />
:as a way to measure the coverage of their SDL and improve security<br />
<br />
;[http://www.nsa.gov/applications/search/index.cfm?q=owasp NSA] <br />
:in their developer guidance on web application security<br />
<br />
;[https://www.pcisecuritystandards.org/index.shtml PCI Council] <br />
:as part of the Payment Card Industry Data Security Standard (PCI DSS)<br />
<br />
;[http://community.citrix.com/display/ocb/2010/06/02/NetScaler+Application+Firewall+and+the+OWASP+Top+10+2010 Citrix] <br />
:in a guide showing how to configure their NetScalar product<br />
<br />
;[http://msdn.microsoft.com/en-us/library/dd129898.aspx Microsoft] <br />
:to show how "T10 threats are handled by the security design and test procedures of Microsoft"<br />
<br />
;[http://www.web2py.com/examples/default/security web2py] <br />
:to demonstrate the security of this Python web framework<br />
<br />
;[http://www.owasp.org/index.php/Commentary_OWASP_Top_Ten_2004_Project Oracle] <br />
:for developer awareness<br />
<br />
;[http://www.theatremanagerhelp.com/book/export/html/1640 TheatreManager] <br />
:to show how their product is secure for web use<br />
<br />
;[http://knol.google.com/k/automated-vulnerabilty-scanners-and-the-owasp-top-10# WhiteHat] <br />
:as a way to explain the coverage of their service<br />
<br />
;[http://www.imperva.com/docs/TB_SecureSphere_OWASP_2010-Top-Ten.pdf Imperva] <br />
:to show the coverage of the SecureSphere tool<br />
<br />
;[http://blog.cenzic.com/public/item/254309 Cenzic] <br />
:to enable "focused scans for compliance testing with the updated PCI standard"<br />
<br />
<br><br />
====Other uses and resources====<br />
<br />
* [[OWASP_Top_10/Mapping_to_WHID | OWASP Top 10 Mapped to the Web Hacking Incident Database]]<br />
<br />
__NOTOC__ <headertabs /><br />
<br />
[[Category:OWASP_Project]] [[Category:OWASP_Document]] [[Category:OWASP_Download]] [[Category:OWASP_Release_Quality_Document]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=File:OWASPTop10_2010_DE_Version_1_0.pdf&diff=120255File:OWASPTop10 2010 DE Version 1 0.pdf2011-11-16T09:14:51Z<p>Kai Jendrian: uploaded a new version of &quot;File:OWASPTop10 DE Version 1 0.pdf&quot;: First uploaded Version was broken...</p>
<hr />
<div>German Translation of OWASP Top 10 2010</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=File:OWASPTop10_2010_DE_Version_1_0.pdf&diff=120254File:OWASPTop10 2010 DE Version 1 0.pdf2011-11-16T08:58:27Z<p>Kai Jendrian: German Translation of OWASP Top 10 2010</p>
<hr />
<div>German Translation of OWASP Top 10 2010</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=120064User:Kai Jendrian2011-11-14T10:15:33Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai.jendrian@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 15 years of Network and Application operations and security<br />
* over 6 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee<br />
* Translation OWASP Top 10 German</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany&diff=116630Germany2011-09-02T08:56:30Z<p>Kai Jendrian: </p>
<hr />
<div>__NOTOC__ <!--<br />
--> <br />
{{Chapter Template|chaptername=Germany<br />
|extra=[[Image:owasp_germany_logo.png|right]]<br />
The chapter leader is [mailto:Georg.Hess@artofdefence.com Georg Heß].<br />
<br />
Chapter Board members are: [mailto:tobias.glemser@owasp.org Tobias Glemser], [mailto:boris@owasp.org Boris Hemkemeier], [mailto:achim@owasp.org Achim Hoffmann], [mailto:ulrike.petersen@owasp.org Uli Petersen], Bruce Sams.<br />
<br />
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-germany<br />
|emailarchives=http://lists.owasp.org/pipermail/owasp-germany<br />
}}<br />
<br />
<br /><br />
<br />
==== OWASP Germany ====<br />
=== OWASP Germany ===<br />
<br />
Herzlich Willkommen auf der Homepage des OWASP German Chapter.<br />
<br />
;Aktuelles: Ankündigung des 4. German OWASP Day 2011 am 17.11.2011 in München<br />
<br />
: Auch dieses Jahr wird es eine Konferenz des German Chapter geben. Details finden Sie auf der [[German OWASP Day 2011|4. German_OWASP_Day_2011]] Homepage.<br />
<!-- alter Name: AppSec Germany<br />
[[OWASP AppSec Germany 2011 Conference|OWASP AppSec Germany 2011 Conference]]<br />
--><br />
<br />
;Mitarbeiter: Wir suchen engagierte Personnen, die das German Chapter als als Ansprechpartner für Firman und Branchen vertreten. Weitere Details folgen in Kürze hier.<br />
<br />
<br />
==== Aktuelles / News ====<br />
<br />
=== Aktuelles / News ===<br />
;Ankündigung: Der 4. German OWASP Day 2011 findet am 17.11.2011 statt, Details finden Sie '''[[German OWASP Day 2011|hier]]'''.<br />
----<br />
*20.01.2011 oder 03.02.2011: Chapter Meeting in Frankfurt <br />
*17.11.2011: German OWASP Day 2011<br />
*19.08.2011: Chapter Board Meeting, Details siehe [[Germany#tab%3dChapter_Meetings|(Tab Chapter Meetings)]]<br />
*09.07.2011: Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kontakt: [[User:Kai_Jendrian|.kai]])<br />
*18.06.2011: Webseite mit neuem Layout<br />
*April 2011: Initiierung des German Language Project<br />
*12 October 2009: [[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]] <br />
*10 September 2008: [[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]] <br />
*17 July 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF_v104.en.pdf|Best Practices: Use of Web Application Firewalls (English)]] *18 March 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF.pdf|Best Practices: Einsatz von Web Application Firewalls (German)]] <br />
*07 September 2007: Chapter meeting in Frankfurt <br />
*18 July 2007: scheduled chapter meeting on September 7th 2007 <br />
*02 Mar 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.bund.de/fachthem/betriebssysteme/indigo/index.htm#indigoen Indigo Security] (engl: 'Indigo Security').<br />
<br />
*23 Feb 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.de/literat/studien/tomcat/index.htm Apache Tomcat Sicherheitsuntersuchung] (engl: 'Apache Tomcat Security Assessment').<br />
<br />
*06 Sept 2006: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30632/WebSec_pdf.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] (engl: 'Measures and Best Practices for Web Application Security').<br />
<br />
*20 May 2006: OWASP Moves to MediaWiki Portal<br />
<br />
OWASP is pleased to announce the arrival of OWASP 2.0! <br />
<br />
OWASP 2.0 utilizes the MediaWiki portal to manage and provide the latest OWASP related information. Enjoy! <br />
<br />
<br />
==== Projekte des German Chapter ====<br />
<br />
== Projektierung der Sicherheitsprüfungen von Webanwendungen ==<br />
<br />
'''[[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]'''<br />
<br />
== Best Practices: Web Application Firewalls ==<br />
<br />
'''[[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]]'''<br />
<br />
== German Language Project ==<br />
<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
Obwohl die ''lingua franca'' <sup>[1]</sup> in der IT Englisch ist, fragen auch Fachleute immer wieder nach Texten in Deutsch. Für einige (Fach-)Artikel gibt es schon Übersetzungen. Inspiriert durch das [[OWASP Spanish|OWASP Spanish Project]] und [[OWASP Portuguese Language Project|OWASP Portuguese Language Project]] ist die Idee entstanden, wichtige Dokumente usw. auch in Deutsch zur Verfügung zu stellen. Einzelne Ansätze dazu gab es zwar schon, diese und weitere werden jetzt zentral üeber das '''[[OWASP German Language Project|OWASP German Language Project]]''' verwaltet.<br />
<br />
Wir laden alle Interessierte herzlich ein mit Kommentaren und Übersetzungen beizutragen und so wichtige Aspekte der Web Application Security auch in Deutsch zu formulieren, so dass ein noch größeres Publikum erreicht wird.<br />
Weiter Detail findet Ihr auf der [[OWASP German Language Project|Projektseite]]. [[User:Mrohr|Matthias Rohr]], der Project Leader, freut sich über Eure tatkräftige Unterstützung.<br />
----<br />
<small>[1] ''lingua franca'', man sieht an diesem Ausdruck, dass auch die Lateiner wussten, welches die Verkehrssprache ist</small> &#9786;<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
The [[OWASP German Language Project|OWASP German Language Project]] is a new OWASP Project that will provide a foundation, guideance and common terminology for German translations. Please contact [[User:Mrohr|Matthias Rohr]], who is the project leader, if you want to participate. Any comments are welcome ...<br />
|} <br />
<br />
==== OWASP Stammtisch-Initiative ====<br />
=== OWASP Stammtisch-Initiative ===<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
In mehren Städten gibt es '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]] ''', bei denen man sich in lockerer Runde im Biergarten oder Gasthaus trifft um sich auszutauschen, nette Leute kennenzulernen oder auch ernsthafte Sicherheitsthemen zu diskutieren. <br />
<br />
Aktive Stammtische gibt es (Stand 2011) in:<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |München]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Köln]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
A "regular's table" (Stammtisch) is a German tradition for meeting each other in a beer garden or a pub in order to discuss certain topics (and to drink beer, of course&nbsp;;-).<br />
<br />
In the case of an '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]]''' it's all about Web Application Security. Right now a Stammtisch is established in <br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |Munich]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Cologne]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
|}<br />
<br />
==== Chapter Meetings ====<br />
<br />
== Chapter Board Meeting am 19.8.2011 in München ==<br />
<br />
=== Agenda ===<br />
* Selbstverständnis Chapter – die Zukunft<br />
* OWASP Germany in „das Bewusstsein“ bringen<br />
* Vereinsgründung ja/nein<br />
* Geldverwaltung/Rechnungen<br />
* Firmen als Chapter Member<br />
* IT-SA 2011<br />
* Board (Kommunikation. Rollen, Wahl, Termin Chapter Meeting)<br />
* Stand der Dinge: Flyer<br />
* OWASP Day<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="65%" style="vertical-align:top; padding-right:0.5em;" |<br />
Das Protokoll des Board-Meetings ist [[Media:Chapter-Germany-20110819-Protokoll.zip|hier]] zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* OWASP Chapter Germany stellt auf der it.sa in Nürnberg aus, 11.10. - 13.10.2011<br />
* es wird eine ''Firmen-Mitgliedschaft'' aka ''Chapter Supporter'' angeboten; Näheres in kürze auf der Webseite<br />
* nächstes Chapter Meeting am 20.01.2011 oder 03.02.2011 in Frankfurt<br />
...<br />
| width="35%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
The protocol of the Chapter Germany Board Meetings can be found [[Media:Chapter-Germany-20110819-Protokoll.zip|here]] . Not that it is in German.<br />
<br />
Most important:<br />
* OWASP Chapter Germany will be at it.sa in Nürnberg, 11.10. - 13.10.2011<br />
* ''Chapter Supporter'' will be possible for companies; details comming soon<br />
* next Chapter Meeting 20.01.2011 or 03.02.2011 in Frankfurt<br />
...<br />
|}<br />
<br />
== Chapter Meeting am 20.5.2010 in München ==<br />
<br />
=== Agenda ===<br />
<br />
* 14:00 Allgemeine Begrüßungs- und Vorstellungsrunde <br />
* 14:15 Bruce Sams: „Strategie und Kosten für ein SDLC“ <br />
* 14:50 Diskussion <br />
* 15:10 Boris Hemkemeier: „Two Factors Are Not Enough“ <br />
* 16:05 Diskussion (geht nahtlos über in die) <br />
* 16:15 Kaffeepause <br />
* 16:35 Vortrag mit Diskussion „Organisatorisches im Chapter“ <br />
* 17:15 Beginn der Beschlussfassungen und Wahlen <br />
* 17:25 Vortrag mit Diskussion „OWASP Germany Conferenc 2010“ <br />
<br />
=== Organisatorisches im Chapter === <br />
<br />
Die Wesentlichen Punkte, die umgesetzt oder verbessert werden sollen: <br />
<br />
* Mehr Außenwirkung durch Public Relations, bessere Pressearbeit / Pressemitteilungen und Einführung und Pflege einer Sprecher- und Rednerliste (um z.B. bei öffentlichen Veranstaltungen OWASP adäquat vorstellen zu können) <br />
* Gepflegtes Wiki sowohl für Außendarstellung als auch als Plattform für die interne Kommunikation <br />
* Einführung von direkten Ansprechpartner für diverse Branchen<br />
<br />
Es folgt eine kurze Diskussion, wie dies effektiv umgesetzt werden kann. Es wird ein Vorschlag durch konkludentes Handeln angenommen: Es soll ein Chapter Board bestehend aus 5 Mitgliedern gewählt werden. Jedes dieser Mitglieder bekommt eine oder mehrere dedizierte Aufgabe(n), um die oben genannten Punkte abzudecken und umzusetzen. Es folgt ein Aufruf, sich für eine entsprechende Wahl zur Verfügung zu stellen. Es soll ebenso der neue Chapter Leader gewählt werden. Da sich nur ein Kandidat für nur einen Posten zur Wahl für die nächsten zwei Jahre zur Verfügung stellt, wird folgendes entschieden: Bei Abstimmungen hat jedes Mitglied des Boards genau eine Stimme, während der Chapter Leader zwei Stimmen hat. So soll zukünftig bei Abstimmungen eine Stimmengleichheit verhindert werden. <br />
<br />
=== Beschluss zur Anzahl der Chapter Leaders ===<br />
<br />
Es wird von den 12 Teilnehmern des Chapter Meetings einstimmig beschlossen, das zukünftig das Chapter Germany (analog zu den meisten anderen OWASP Chapters) nur noch einen Chapter Leader hat. <br />
<br />
=== Wahl des Chapter Leaders ===<br />
<br />
'''Georg Heß''' kandidiert als Chapter Leader und wird mit 11 von 12 Stimmen bei einer Enthaltung zum neuen Chapter Leader des OWASP Chapters Germany gewählt. <br />
<br />
=== Beschluss zur zukünftigen Zusammensetzung des Boards ===<br />
<br />
Einstimmig wird beschlossen, dass das zukünftige Board aus 5 Mitgliedern besteht. Diese sollen die Aufgaben wie in der Diskussion beschrieben wahr nehmen. <br />
<br />
=== Wahl des Boards ===<br />
<br />
Es kandidieren '''Tobias Glemser, Boris Hemkemeier, Achim Hoffmann, Uli Petersen und Bruce Sams ''' für die 5 Sitze im Board. Alle werden einstimmig gewählt. <br />
<br />
Alle Gewählten nehmen die Wahl an. <br />
<br />
=== OWASP AppSec 2010 ===<br />
<br />
Es folgt ein kurzer historischer Rückblick der Veranstaltungsorte: 2008 im Hotel in Frankfurt, 2009 auf der Messe it-sa in Nürnberg. Kurze Diskussion pro und contra Hotel vs. Messe vs. Hochschul-Location. <br />
<br />
* Es soll geprüft werden, ob die diesjährige '''„OWASP Germany Conference 2010“''' wieder in Kooperation mit der Messe Nürnberg / it-sa durchgeführt werden kann (z.B. am 20.10.2010). <br />
* Weiterhin ist ein Konferenztag mit '''zwei verschiedenen Tracks (Technik und Management)''' angedacht. <br />
* Um die inhaltliche Gestaltung voranzutreiben wird ein '''Programm-Komitee''' (initial bestehend aus '''Bruce Sams, Kai Jendrian, Boris Hemkemeier und Martin Johns''') ins Leben gerufen, das alsbald den '''CFP''' starten soll.<br />
<br />
Gegen 18:15 löst sich das OWASP German Chapter Meeting auf und geht nahtlos in den 12. „Happy Anniversary!“ OWASP Stammtisch München über.<br />
<br />
== OWASP German Chapter Meeting - February 20th, 2008 in Darmstadt ==<br />
<br />
;Date: February 20th, 2008, 11:00-16:15<br />
;Location: Darmstadt, CAST (http://www.cast-forum.de)'''<br> Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt]<br />
<br />
The next chapter meeting will be hosted at CAST in Darmstadt.<br> This time the focus is on technical presentations and discussion. <br> <br> <br />
<br />
;Agenda: Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion. <br />
*1. (11:00 - 11:15) Welcome, Introduction and Administrativia <br />
*2. (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann) <br />
*3. (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom) <br />
*4. (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Slides: [http://www.owasp.org/images/1/1b/WAF-Paper.pdf PDF]) (Alexander Meisel) <br />
*5. (12:30 - 13:15) Break <br />
*6. (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann) <br />
*7. (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss) <br />
**"Input validation in ASP.NET -- tips, tricks &amp; pitfalls" (Boris Hemkemeier) <br />
**"Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel) <br />
*8. (14:45 - 15:00) Coffee Break <br />
*9. (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias) <br />
*10. (15:45 - 16:00) Wrap-up and outlook<br />
<br />
<br> <br />
<br />
== Chapter Meeting on September 7th 2007 in Frankfurt/Main ==<br />
<br />
After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00. <br />
<br />
This first chapter meeting had as its main goal the re-initiation of the German chapter and to start work on projects. Talks and presentations are secondary and will receive more focus at subsequent meetings. <br />
<br />
'''[https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html Read meeting notes/minutes here]''' <br />
<br />
<br />
==== Past Events ====<br />
<br />
== OWASP AppSec Germany 2010 Conference 20.10.2010 in Nürnberg ==<br />
[[OWASP AppSec Germany 2010 Conference]]<br />
<br />
== OWASP AppSec Germany 2009 Conference 13.10.09, Nürnberg ==<br />
<br />
Die OWASP AppSec Germany 2009 Conference fand am 13.10.09 mit einer Vorabendveranstalung am 12.10.09 in Nürnberg statt.<br>(The OWASP AppSec Germany 2009 conference will be held on October 13, 2009 in Nürnberg)<br />
;Die Vorträge<br />
* Vorstellung des Open Web Application Security Project<br />
* OWASP Education Project<br />
* Praktische Erfahrung mit dem Secure Software Lifecycle<br />
* Sichere Entwicklung und gängige Schwachstellen in eigenentwickelten SAP-Web-Anwendungen<br />
* Adaptive Sicherheit durch Anomalieerkennung<br />
* Design Bugs<br />
* JavaScript aus der Hölle - advanced client side injection techniques of tomorrow<br />
* Projektierung der Sicherheitsprüfung von Webanwendungenen<br />
* Pentestvorbereitung: Sitemap für Webanwendungen (Tools)<br />
<br />
== OWASP German Chapter Meeting 10.07.2009, Mannheim ==<br />
<br />
;Summary:We will start with three interesting fresh talks. The following topics are the next activities of the OWASP German Chapter: the new [http://www.owasp.org/index.php/OWASP_German_Chapter_Stammtisch_Initiative "Stammtisch Initiative"] and the planning of the [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009] at Nuremberg. <br />
<br />
;Location:Aula of the [http://www.hs-mannheim.de Hochschule Mannheim], Building 3, Paul-Wittsack-Strasse 10, Mannheim ([http://maps.google.de/maps?f=d&source=s_d&saddr=Mannheim+Hbf&daddr=49.471303,8.48372&geocode=Fbr-8gIduTmBAA%3B&hl=de&mra=dme&mrcr=0&mrsp=1&sz=15&sll=49.474885,8.474715&sspn=0.015532,0.050254&ie=UTF8&z=15 Google Maps]). Please download the [http://www.hs-mannheim.de/campus/grafik/campusplan_legende_web.pdf campus map]. <br />
<br />
;Agenda:<br />
<br />
* 12:00 - 13:00&nbsp;: Lunch (optional, please send an email to [mailto:Georg.Hess@artofdefence.com?subject=OWASP%20Chapter%20Meeting%20Lunch%20registration Georg Heß] to register for lunch), meeting point for the lunch is at the Aula in Building 3<br />
* 13:15 - 13:30 : Opening by our host Prof. Rainer Gerten (German) <br />
* 13:30 - 14:30 : OWASP Educational Services - Teaching Security!, Martin Knobloch, Member of OWASP Global Education Committee (English) <br />
* 14:30 - 15:00 : Vorstellung und aktueller Stand des OWASP Germany Projekts "Best Practice: Projektierung von Sicherheitsprüfungen von Web Applikationen", N.N., Projekt-Mitarbeiter (German) <br />
* 15:00 - 15:45 : Cloud Application Security - Chancen und Risiken - Einige Ansatzpunkte zum Thema, Georg Hess (German) <br />
* 15:45 - 16:15 : Coffee <br />
* 16:15 - 17:00 : Organisational topics of the OWASP German Chapter (German) <br />
** OWASP Stammtisch Initiative <br />
** Outlook and organisational tasks for the 2nd [[OWASP Germany 2009 Conference]]<br />
* nach 17:00 : Come together (Any ideas for a near pub??) <br />
<br />
;Minutes: [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html See the list archive for the minutes.]<br />
<br />
== Wir sind auf der SYSTEMS 08 in München ==<br />
<br />
Besuchen Sie uns vom 21.10. - 24.10.08 in der <br />
<br />
:'''IT-SecurityArea - Halle B3, Stand 228'''<br />
<br />
== OWASP Germany 2008 Conference 25.11.08 in Frankfurt ==<br />
<br />
Die [[OWASP Germany 2008 Conference]] wird am 25.11.08 mit einer Vorabendveranstalung am 24.11.08 in Frankfurt stattfinden. <br />
(The OWASP Germany 2008 conference will be held on November 25, 2008 in Frankfurt.) <br />
<br />
<br />
==== Comments ====<br />
=== Comments ===<br />
If you want to participate in the work of the German OWASP chapter or offer to submit work to it and cannot attend the meeting, please contact any of the German Chapter Board members (see above) or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list]. <br />
<br />
==== Press Relations ====<br />
=== Press Relations ===<br />
Press Relations of the OWASP German Chapter are currently directed exclusively towards the local press. We therefore do not provide english translations.<br />
<br />
*[http://www.owasp.org/index.php?title=Germany/press Press relations]<br />
<br />
<br />
<headertabs /><br />
<br />
[[Category:Germany]]<br />
[[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany&diff=116629Germany2011-09-02T08:55:30Z<p>Kai Jendrian: </p>
<hr />
<div>__NOTOC__ <!--<br />
--> <br />
{{Chapter Template|chaptername=Germany<br />
|extra=[[Image:owasp_germany_logo.png|right]]<br />
The chapter leader is [mailto:Georg.Hess@artofdefence.com Georg Heß].<br />
<br />
Chapter Board members are: [mailto:tobias.glemser@owasp.org Tobias Glemser], [mailto:boris@owasp.org Boris Hemkemeier], [mailto:achim@owasp.org Achim Hoffmann], [mailto:ulrike.petersen@owasp.org Uli Petersen], Bruce Sams.<br />
<br />
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-germany<br />
|emailarchives=http://lists.owasp.org/pipermail/owasp-germany<br />
}}<br />
<br />
<br /><br />
<br />
==== OWASP Germany ====<br />
=== OWASP Germany ===<br />
<br />
Herzlich Willkommen auf der Homepage des OWASP German Chapter.<br />
<br />
;Aktuelles: Ankündigung des 4. German OWASP Day 2011 am 17.11.2011 in München<br />
<br />
: Auch dieses Jahr wird es eine Konferenz des German Chapter geben. Details finden Sie auf der [[German OWASP Day 2011|4. German_OWASP_Day_2011]] Homepage.<br />
<!-- alter Name: AppSec Germany<br />
[[OWASP AppSec Germany 2011 Conference|OWASP AppSec Germany 2011 Conference]]<br />
--><br />
<br />
;Mitarbeiter: Wir suchen engagierte Personnen, die das German Chapter als als Ansprechpartner für Firman und Branchen vertreten. Weitere Details folgen in Kürze hier.<br />
<br />
<br />
==== Aktuelles / News ====<br />
<br />
=== Aktuelles / News ===<br />
;Ankündigung: Der 4. German OWASP Day 2011 findet am 17.11.2011 statt, Details finden Sie '''[[German OWASP Day 2011|hier]]'''.<br />
----<br />
*20.01.2011 oder 03.02.2011: Chapter Meeting in Frankfurt <br />
*17.11.2011: German OWASP Day 2011<br />
*19.08.2011: Chapter Board Meeting, Details siehe [[Germany#tab%3dChapter_Meetings|(Tab Chapter Meetings)]]<br />
*09.07.2011: Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kontakt: [[User:Kai_Jendrian|.kai]])<br />
*18.06.2011: Webseite mit neuem Layout<br />
*April 2011: Initiierung des German Language Project<br />
*12 October 2009: [[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]] <br />
*10 September 2008: [[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]] <br />
*17 July 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF_v104.en.pdf|Best Practices: Use of Web Application Firewalls (English)]] *18 March 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF.pdf|Best Practices: Einsatz von Web Application Firewalls (German)]] <br />
*07 September 2007: Chapter meeting in Frankfurt <br />
*18 July 2007: scheduled chapter meeting on September 7th 2007 <br />
*02 Mar 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.bund.de/fachthem/betriebssysteme/indigo/index.htm#indigoen Indigo Security] (engl: 'Indigo Security').<br />
<br />
*23 Feb 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.de/literat/studien/tomcat/index.htm Apache Tomcat Sicherheitsuntersuchung] (engl: 'Apache Tomcat Security Assessment').<br />
<br />
*06 Sept 2006: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30632/WebSec_pdf.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] (engl: 'Measures and Best Practices for Web Application Security').<br />
<br />
*20 May 2006: OWASP Moves to MediaWiki Portal<br />
<br />
OWASP is pleased to announce the arrival of OWASP 2.0! <br />
<br />
OWASP 2.0 utilizes the MediaWiki portal to manage and provide the latest OWASP related information. Enjoy! <br />
<br />
<br />
==== Projekte des German Chapter ====<br />
<br />
== Projektierung der Sicherheitsprüfungen von Webanwendungen ==<br />
<br />
'''[[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]'''<br />
<br />
== Best Practices: Web Application Firewalls ==<br />
<br />
'''[[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]]'''<br />
<br />
== German Language Project ==<br />
<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
Obwohl die ''lingua franca'' <sup>[1]</sup> in der IT Englisch ist, fragen auch Fachleute immer wieder nach Texten in Deutsch. Für einige (Fach-)Artikel gibt es schon Übersetzungen. Inspiriert durch das [[OWASP Spanish|OWASP Spanish Project]] und [[OWASP Portuguese Language Project|OWASP Portuguese Language Project]] ist die Idee entstanden, wichtige Dokumente usw. auch in Deutsch zur Verfügung zu stellen. Einzelne Ansätze dazu gab es zwar schon, diese und weitere werden jetzt zentral üeber das '''[[OWASP German Language Project|OWASP German Language Project]]''' verwaltet.<br />
<br />
Wir laden alle Interessierte herzlich ein mit Kommentaren und Übersetzungen beizutragen und so wichtige Aspekte der Web Application Security auch in Deutsch zu formulieren, so dass ein noch größeres Publikum erreicht wird.<br />
Weiter Detail findet Ihr auf der [[OWASP German Language Project|Projektseite]]. [[User:Mrohr|Matthias Rohr]], der Project Leader, freut sich über Eure tatkräftige Unterstützung.<br />
----<br />
<small>[1] ''lingua franca'', man sieht an diesem Ausdruck, dass auch die Lateiner wussten, welches die Verkehrssprache ist</small> &#9786;<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
The [[OWASP German Language Project|OWASP German Language Project]] is a new OWASP Project that will provide a foundation, guideance and common terminology for German translations. Please contact [[User:Mrohr|Matthias Rohr]], who is the project leader, if you want to participate. Any comments are welcome ...<br />
|} <br />
<br />
==== OWASP Stammtisch-Initiative ====<br />
=== OWASP Stammtisch-Initiative ===<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
In mehren Städten gibt es '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]] ''', bei denen man sich in lockerer Runde im Biergarten oder Gasthaus trifft um sich auszutauschen, nette Leute kennenzulernen oder auch ernsthafte Sicherheitsthemen zu diskutieren. <br />
<br />
Aktive Stammtische gibt es (Stand 2011) in:<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |München]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Köln]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Karlsruhe |Karlsruhe]]<br />
<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
A "regular's table" (Stammtisch) is a German tradition for meeting each other in a beer garden or a pub in order to discuss certain topics (and to drink beer, of course&nbsp;;-).<br />
<br />
In the case of an '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]]''' it's all about Web Application Security. Right now a Stammtisch is established in <br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |Munich]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Cologne]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Hamburg |Hamburg]]<br />
|}<br />
<br />
==== Chapter Meetings ====<br />
<br />
== Chapter Board Meeting am 19.8.2011 in München ==<br />
<br />
=== Agenda ===<br />
* Selbstverständnis Chapter – die Zukunft<br />
* OWASP Germany in „das Bewusstsein“ bringen<br />
* Vereinsgründung ja/nein<br />
* Geldverwaltung/Rechnungen<br />
* Firmen als Chapter Member<br />
* IT-SA 2011<br />
* Board (Kommunikation. Rollen, Wahl, Termin Chapter Meeting)<br />
* Stand der Dinge: Flyer<br />
* OWASP Day<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="65%" style="vertical-align:top; padding-right:0.5em;" |<br />
Das Protokoll des Board-Meetings ist [[Media:Chapter-Germany-20110819-Protokoll.zip|hier]] zu finden; das Passwort ist geheim ;-)<br />
<br />
Wichtige Entscheidungen in Kürze:<br />
* OWASP Chapter Germany stellt auf der it.sa in Nürnberg aus, 11.10. - 13.10.2011<br />
* es wird eine ''Firmen-Mitgliedschaft'' aka ''Chapter Supporter'' angeboten; Näheres in kürze auf der Webseite<br />
* nächstes Chapter Meeting am 20.01.2011 oder 03.02.2011 in Frankfurt<br />
...<br />
| width="35%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
The protocol of the Chapter Germany Board Meetings can be found [[Media:Chapter-Germany-20110819-Protokoll.zip|here]] . Not that it is in German.<br />
<br />
Most important:<br />
* OWASP Chapter Germany will be at it.sa in Nürnberg, 11.10. - 13.10.2011<br />
* ''Chapter Supporter'' will be possible for companies; details comming soon<br />
* next Chapter Meeting 20.01.2011 or 03.02.2011 in Frankfurt<br />
...<br />
|}<br />
<br />
== Chapter Meeting am 20.5.2010 in München ==<br />
<br />
=== Agenda ===<br />
<br />
* 14:00 Allgemeine Begrüßungs- und Vorstellungsrunde <br />
* 14:15 Bruce Sams: „Strategie und Kosten für ein SDLC“ <br />
* 14:50 Diskussion <br />
* 15:10 Boris Hemkemeier: „Two Factors Are Not Enough“ <br />
* 16:05 Diskussion (geht nahtlos über in die) <br />
* 16:15 Kaffeepause <br />
* 16:35 Vortrag mit Diskussion „Organisatorisches im Chapter“ <br />
* 17:15 Beginn der Beschlussfassungen und Wahlen <br />
* 17:25 Vortrag mit Diskussion „OWASP Germany Conferenc 2010“ <br />
<br />
=== Organisatorisches im Chapter === <br />
<br />
Die Wesentlichen Punkte, die umgesetzt oder verbessert werden sollen: <br />
<br />
* Mehr Außenwirkung durch Public Relations, bessere Pressearbeit / Pressemitteilungen und Einführung und Pflege einer Sprecher- und Rednerliste (um z.B. bei öffentlichen Veranstaltungen OWASP adäquat vorstellen zu können) <br />
* Gepflegtes Wiki sowohl für Außendarstellung als auch als Plattform für die interne Kommunikation <br />
* Einführung von direkten Ansprechpartner für diverse Branchen<br />
<br />
Es folgt eine kurze Diskussion, wie dies effektiv umgesetzt werden kann. Es wird ein Vorschlag durch konkludentes Handeln angenommen: Es soll ein Chapter Board bestehend aus 5 Mitgliedern gewählt werden. Jedes dieser Mitglieder bekommt eine oder mehrere dedizierte Aufgabe(n), um die oben genannten Punkte abzudecken und umzusetzen. Es folgt ein Aufruf, sich für eine entsprechende Wahl zur Verfügung zu stellen. Es soll ebenso der neue Chapter Leader gewählt werden. Da sich nur ein Kandidat für nur einen Posten zur Wahl für die nächsten zwei Jahre zur Verfügung stellt, wird folgendes entschieden: Bei Abstimmungen hat jedes Mitglied des Boards genau eine Stimme, während der Chapter Leader zwei Stimmen hat. So soll zukünftig bei Abstimmungen eine Stimmengleichheit verhindert werden. <br />
<br />
=== Beschluss zur Anzahl der Chapter Leaders ===<br />
<br />
Es wird von den 12 Teilnehmern des Chapter Meetings einstimmig beschlossen, das zukünftig das Chapter Germany (analog zu den meisten anderen OWASP Chapters) nur noch einen Chapter Leader hat. <br />
<br />
=== Wahl des Chapter Leaders ===<br />
<br />
'''Georg Heß''' kandidiert als Chapter Leader und wird mit 11 von 12 Stimmen bei einer Enthaltung zum neuen Chapter Leader des OWASP Chapters Germany gewählt. <br />
<br />
=== Beschluss zur zukünftigen Zusammensetzung des Boards ===<br />
<br />
Einstimmig wird beschlossen, dass das zukünftige Board aus 5 Mitgliedern besteht. Diese sollen die Aufgaben wie in der Diskussion beschrieben wahr nehmen. <br />
<br />
=== Wahl des Boards ===<br />
<br />
Es kandidieren '''Tobias Glemser, Boris Hemkemeier, Achim Hoffmann, Uli Petersen und Bruce Sams ''' für die 5 Sitze im Board. Alle werden einstimmig gewählt. <br />
<br />
Alle Gewählten nehmen die Wahl an. <br />
<br />
=== OWASP AppSec 2010 ===<br />
<br />
Es folgt ein kurzer historischer Rückblick der Veranstaltungsorte: 2008 im Hotel in Frankfurt, 2009 auf der Messe it-sa in Nürnberg. Kurze Diskussion pro und contra Hotel vs. Messe vs. Hochschul-Location. <br />
<br />
* Es soll geprüft werden, ob die diesjährige '''„OWASP Germany Conference 2010“''' wieder in Kooperation mit der Messe Nürnberg / it-sa durchgeführt werden kann (z.B. am 20.10.2010). <br />
* Weiterhin ist ein Konferenztag mit '''zwei verschiedenen Tracks (Technik und Management)''' angedacht. <br />
* Um die inhaltliche Gestaltung voranzutreiben wird ein '''Programm-Komitee''' (initial bestehend aus '''Bruce Sams, Kai Jendrian, Boris Hemkemeier und Martin Johns''') ins Leben gerufen, das alsbald den '''CFP''' starten soll.<br />
<br />
Gegen 18:15 löst sich das OWASP German Chapter Meeting auf und geht nahtlos in den 12. „Happy Anniversary!“ OWASP Stammtisch München über.<br />
<br />
== OWASP German Chapter Meeting - February 20th, 2008 in Darmstadt ==<br />
<br />
;Date: February 20th, 2008, 11:00-16:15<br />
;Location: Darmstadt, CAST (http://www.cast-forum.de)'''<br> Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt]<br />
<br />
The next chapter meeting will be hosted at CAST in Darmstadt.<br> This time the focus is on technical presentations and discussion. <br> <br> <br />
<br />
;Agenda: Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion. <br />
*1. (11:00 - 11:15) Welcome, Introduction and Administrativia <br />
*2. (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann) <br />
*3. (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom) <br />
*4. (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Slides: [http://www.owasp.org/images/1/1b/WAF-Paper.pdf PDF]) (Alexander Meisel) <br />
*5. (12:30 - 13:15) Break <br />
*6. (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann) <br />
*7. (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss) <br />
**"Input validation in ASP.NET -- tips, tricks &amp; pitfalls" (Boris Hemkemeier) <br />
**"Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel) <br />
*8. (14:45 - 15:00) Coffee Break <br />
*9. (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias) <br />
*10. (15:45 - 16:00) Wrap-up and outlook<br />
<br />
<br> <br />
<br />
== Chapter Meeting on September 7th 2007 in Frankfurt/Main ==<br />
<br />
After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00. <br />
<br />
This first chapter meeting had as its main goal the re-initiation of the German chapter and to start work on projects. Talks and presentations are secondary and will receive more focus at subsequent meetings. <br />
<br />
'''[https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html Read meeting notes/minutes here]''' <br />
<br />
<br />
==== Past Events ====<br />
<br />
== OWASP AppSec Germany 2010 Conference 20.10.2010 in Nürnberg ==<br />
[[OWASP AppSec Germany 2010 Conference]]<br />
<br />
== OWASP AppSec Germany 2009 Conference 13.10.09, Nürnberg ==<br />
<br />
Die OWASP AppSec Germany 2009 Conference fand am 13.10.09 mit einer Vorabendveranstalung am 12.10.09 in Nürnberg statt.<br>(The OWASP AppSec Germany 2009 conference will be held on October 13, 2009 in Nürnberg)<br />
;Die Vorträge<br />
* Vorstellung des Open Web Application Security Project<br />
* OWASP Education Project<br />
* Praktische Erfahrung mit dem Secure Software Lifecycle<br />
* Sichere Entwicklung und gängige Schwachstellen in eigenentwickelten SAP-Web-Anwendungen<br />
* Adaptive Sicherheit durch Anomalieerkennung<br />
* Design Bugs<br />
* JavaScript aus der Hölle - advanced client side injection techniques of tomorrow<br />
* Projektierung der Sicherheitsprüfung von Webanwendungenen<br />
* Pentestvorbereitung: Sitemap für Webanwendungen (Tools)<br />
<br />
== OWASP German Chapter Meeting 10.07.2009, Mannheim ==<br />
<br />
;Summary:We will start with three interesting fresh talks. The following topics are the next activities of the OWASP German Chapter: the new [http://www.owasp.org/index.php/OWASP_German_Chapter_Stammtisch_Initiative "Stammtisch Initiative"] and the planning of the [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009] at Nuremberg. <br />
<br />
;Location:Aula of the [http://www.hs-mannheim.de Hochschule Mannheim], Building 3, Paul-Wittsack-Strasse 10, Mannheim ([http://maps.google.de/maps?f=d&source=s_d&saddr=Mannheim+Hbf&daddr=49.471303,8.48372&geocode=Fbr-8gIduTmBAA%3B&hl=de&mra=dme&mrcr=0&mrsp=1&sz=15&sll=49.474885,8.474715&sspn=0.015532,0.050254&ie=UTF8&z=15 Google Maps]). Please download the [http://www.hs-mannheim.de/campus/grafik/campusplan_legende_web.pdf campus map]. <br />
<br />
;Agenda:<br />
<br />
* 12:00 - 13:00&nbsp;: Lunch (optional, please send an email to [mailto:Georg.Hess@artofdefence.com?subject=OWASP%20Chapter%20Meeting%20Lunch%20registration Georg Heß] to register for lunch), meeting point for the lunch is at the Aula in Building 3<br />
* 13:15 - 13:30 : Opening by our host Prof. Rainer Gerten (German) <br />
* 13:30 - 14:30 : OWASP Educational Services - Teaching Security!, Martin Knobloch, Member of OWASP Global Education Committee (English) <br />
* 14:30 - 15:00 : Vorstellung und aktueller Stand des OWASP Germany Projekts "Best Practice: Projektierung von Sicherheitsprüfungen von Web Applikationen", N.N., Projekt-Mitarbeiter (German) <br />
* 15:00 - 15:45 : Cloud Application Security - Chancen und Risiken - Einige Ansatzpunkte zum Thema, Georg Hess (German) <br />
* 15:45 - 16:15 : Coffee <br />
* 16:15 - 17:00 : Organisational topics of the OWASP German Chapter (German) <br />
** OWASP Stammtisch Initiative <br />
** Outlook and organisational tasks for the 2nd [[OWASP Germany 2009 Conference]]<br />
* nach 17:00 : Come together (Any ideas for a near pub??) <br />
<br />
;Minutes: [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html See the list archive for the minutes.]<br />
<br />
== Wir sind auf der SYSTEMS 08 in München ==<br />
<br />
Besuchen Sie uns vom 21.10. - 24.10.08 in der <br />
<br />
:'''IT-SecurityArea - Halle B3, Stand 228'''<br />
<br />
== OWASP Germany 2008 Conference 25.11.08 in Frankfurt ==<br />
<br />
Die [[OWASP Germany 2008 Conference]] wird am 25.11.08 mit einer Vorabendveranstalung am 24.11.08 in Frankfurt stattfinden. <br />
(The OWASP Germany 2008 conference will be held on November 25, 2008 in Frankfurt.) <br />
<br />
<br />
==== Comments ====<br />
=== Comments ===<br />
If you want to participate in the work of the German OWASP chapter or offer to submit work to it and cannot attend the meeting, please contact any of the German Chapter Board members (see above) or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list]. <br />
<br />
==== Press Relations ====<br />
=== Press Relations ===<br />
Press Relations of the OWASP German Chapter are currently directed exclusively towards the local press. We therefore do not provide english translations.<br />
<br />
*[http://www.owasp.org/index.php?title=Germany/press Press relations]<br />
<br />
<br />
<headertabs /><br />
<br />
[[Category:Germany]]<br />
[[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=OWASP_German_Chapter_Stammtisch_Initiative&diff=116375OWASP German Chapter Stammtisch Initiative2011-08-29T05:49:51Z<p>Kai Jendrian: </p>
<hr />
<div>== Was ist ein OWASP Stammtisch? ==<br />
<br />
Ein OWASP Stammtisch ist ein regelmäßiges Treffen von OWASP Interessierten in einem Restaurant oder einer Gaststätte. Es gibt zumeist kein festes Programm mit Vorträgen. Der Austausch von Ideen und Erfahrungen soll im Vordergrund stehen. In kleineren Gruppen reicht ein Laptop für Präsentationen, da zumeist keine technischen Möglichkeiten für Vorführungen vorhanden sind. <br />
<br />
Ein lokaler Verantworlicher lädt zum Stammtisch über die German Chapter Mailing Liste ein. Es gelten grundästzlich dieselben [http://www.owasp.org/index.php/Chapter_Rules Regeln wie bei Chapter Meetings]. <br />
<br />
Die lokalen OWASP Stammtische sollen Interessierten Gelegenheit zum Austausch und zum Knüpfen von Kontakten geben. Wenn Sie OWASP selbst kennen lernen wollen, dann besuchen Sie einen Stammtisch in Ihrer Nähe. Wenn es noch keinen gibt, dann gründen Sie einfach einen. <br />
<br />
== Stammtisch oder Chapter? ==<br />
<br />
Stammtische sind keine Konkurrenz für Chapter sondern eine willkommene Ergänzung. Sie ermöglichen regelmäßige Treffen im Rahmen der OWASP-Community ohne die organisatorischen Hürden für einen regulären Chapter-Betrieb. Erreicht ein Stammtisch die "kritische" Masse für einen Chapter-Betrieb, dann ist eine Aufwertung in eine lokale Chapter-Gründung ebenfalls höchst willkommen. <br />
<br />
<br> <br />
<br />
== Lokale Stammtische ==<br />
<br />
==== München ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Münchner Stammtisch findet '''jeden dritten Dienstag im Monat um 19:00 Uhr '''im Restaurant und Biergarten '''"Cafe Waldfrieden"''' in der '''Fürstenrieder Str. 277''' in '''81377 München''' statt. <br> <br />
<br />
Es ist immer für 12 Personen reserviert, bei gutem Wetter (t &gt; 20,0 °C gefühlt, kein Niederschlag, Tageslicht) im Biergarten, bei schlechtem Wetter im Nebenraum - im Zweifelsfall bitte einfach am Tresen nach dem OWASP-Stammtisch fragen. Um vorhergehende '''Anmeldung per Mail bei [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] wird gebeten''', um ggf. weitere Ressourcen reservieren zu lassen - '''spontane "Zaungäste" sind aber jederzeit ebenso willkommen'''. <br />
<br />
===== Der 26. Münchner OWASP Stammtisch am 16.08.2011 =====<br />
<br />
Dieser Stammtisch hat kein dediziertes Thema, der ursprünglich geplante Rückblick auf das Chaos Communication Camp 2011 wird um vier Wochen verschoben (um ein paar Bilder / Videos / Slides zeigen zu können).<br />
<br />
===== Um 19:00 im <i>"Cafe Waldfrieden"</i> ===== <br />
Cafe Waldfrieden<br><br />
Fürstenrieder Str. 277<br><br />
81377 München<br><br />
<br />
Telefon: (089) 7244 1429<br><br />
<br />
Das Cafe befindet sich direkt gegenüber des Haupteingangs des Waldfriedhofs.<br><br />
<br />
Öffentlicher Nahverkehr: <br />
U-Bahn <b>U6</b>, Haltestelle <b>Holzapfelkreuth</b><br />
oder <b>Stadtbus 151</b>, Haltestelle <b>Waldfriedhof</b> <br />
<br />
Nützliche Links: [http://maps.google.com/maps/place?cid=6980435847828545857 Google Maps, "Places"] oder [http://maps.google.com/maps?q=Fürstenrieder+Straße+277%2C+münchen&btnG=Maps-Suche Google Maps, direkte Adresse] und [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen].<br />
<!--<br />
Georg-Zech-Allee 15<br> 80995 München<br> Tel.: 089 - 31 47 663<br> <br />
<br />
[http://www.schlemmerregion-muenchen.de/rp_restaurant_kurzinfo.afp?!_2RJ1E8VY3&bl=D00&rid=_0S50REUPA&rve=5701B98n Info],[http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=+Georg-Zech-Allee+15,+m%C3%BCnchen&sll=48.140232,11.545644&sspn=0.006801,0.018775&ie=UTF8&ll=48.209117,11.531417&spn=0.006792,0.018775&z=16&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br> <br />
<br />
Gasthaus Löwe und Raute<br> Nymphenburger Str. 64<br> 80335 München<br> Tel. 089 / 130 143 97<br> <br />
<br />
[http://www.loeweundraute.com Homepage], [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=Nymphenburger+Str.+64,+m%C3%BCnchen&sll=53.87844,6.152344&sspn=10.478551,38.012695&ie=UTF8&ll=48.152373,11.548777&spn=0.011567,0.037122&z=15&iwloc=A Google Maps], [http://www.mvv-muenchen.de/de/home/fahrgastinformation/efa/fahrtauskunft/index.html MVV zum selber tippen] <br />
--><br />
<br />
===== Geplante Stammtisch-Vorträge =====<br />
<br />
Für den 27. Stammtisch am 20.09.2011: Das OWASP-Zelt auf dem [http://events.ccc.de/camp/2011/wiki/OWASP Chaos Communication Camp 2011] in Berlin, der bisher größten Open Air Hacker-Party des Jahrzehnts ;-) - ein Rückblick.<br />
<br />
Denkbare Vortrags-Themen an einem der zukünftigen Stammtische: <br />
<br />
*Dein Thema hier! :-)<br />
<br />
Sobald wir eine konkrete Zusage haben, werde ich das bei der Ankündigung des jeweiligen Termins mit bekannt geben.<br> <br />
<br />
Also, wie immer: Ich bitte um kurze Info an mich, ob jemand noch weitere (für uns relevante) Themen parat hat, die er uns näher bringen möchte. ''Verkaufsveranstalter werden alle 20 Minuten ausgebuht und müssen dann eine (neue) Runde Bier bezahlen.''<br><br />
<br />
===== Bereits gehaltene Stammtisch-Vorträge =====<br />
<br />
*Juni 2011: Rückblick und Würdigung der [https://www.owasp.org/index.php/AppSecEU2011 OWASP AppSec Europe 2011 in Dublin] (Andreas von Keviczky)<br />
*Februar 2011: Nachklapp zum [http://www.owasp.org/index.php/Summit_2011/Summit_Results_Summary OWASP Summit 2011 in Portugal] (Achim Hoffmann und Ralf Reinhardt) <br />
*Januar 2011: Offene Diskussion über die Sicherheit von mobilen Endgeräten bei Einsatz im Firmennetz und 'in the wild' (Matthias Trojahn)<br />
*November 2010: Vektorbasierte Anomalien-Erkennung in HTTP-Traffic (Michael Kirchner), [http://students.fh-hagenberg.at/sec/s0810304003/Thesis_Anomalieerkennung_in_HTTP-Daten_Vortrag_OWASP.pdf Folien].<br />
*Juni 2010: Aus der Werkzeug-Schatzkiste des gehobenen Pentesters (Uli Petersen und Achim Hoffmann), u.a. wurde [http://www.owasp.org/index.php/Category:OWASP_EnDe "EnDe"] besprochen.<br />
*März 2010: ISO/IEC 27001 (Barbara Schachner und Feiliang Wu)<br />
*November 2009: Was eine WAF (nicht) kann ([https://mirko.dziadzka.de/ Mirko Dziadzka]), [https://mirko.dziadzka.de/Vortrag/owasp-waf-20091124.pdf Folien]. <br />
*Oktober 2009: Eine Kurzeinführung in Injection-Angriffe (Ralf Reinhardt)<br />
<br />
===== Spread the word =====<br />
<br />
Wie immer möchte ich jeden bitten, der Menschen kennt, von denen er sich vorstellen könnte, dass Sie kommen möchten und könnten, diese Einladung an eben diese Menschen weiter zu leiten.<br> <br />
<br />
Thema und hinreichende Bedingung ist in erster Linie Web Application Security. Man muss überhaupt nichts von OWASP wissen, ein vorhergehender Blick auf die Website indes schadet sicher nicht.<br> <br />
<br />
Schönen Gruß, [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt] <br />
<br />
==== Frankfurt ====<br />
<br />
===== Mitorganisator für den Frankfurter Stammtisch gesucht =====<br />
OWASP ist eine aktive Community und zusammen geht alles besser. Damit der Stammtisch regelmäßig stattffinden kann und für die Teilnehmer Planungssicherheit herrscht möchte ich gerne eine Co-Moderatorin oder einen Co-Moderator für die Organisation hinzugewinnen. Das Treffen soll nich gleich ausfallen, wenn der Organisator kurzfristig verhindert ist. Der Arbeitsaufwand ist sehr überschaubar. Eine [https://www.owasp.org/index.php/Membership Mitgliedschaft] bei OWASP ist nicht erforderlich, aber natürlich erwünscht :-) Dann gibt es auch eine "foo.bar@owasp.org" Emailadresse. Wer sich dafür interessiert, möge sich bitte bei [mailto:boris@owasp.org Boris Hemkemeier] melden.<br />
<br />
===== Allgemeines =====<br />
<br />
Ähnlich wie in München soll der Stammtisch hauptsächlich zum lockeren Austausch und Netzwerken dienen. <br />
<br />
Eingeladen sind alle Interessierten an <br />
<br />
*Application Security <br />
*Web Application Security <br />
*Secure Software Lifecycle <br />
*Security-Awareness Programme für Entwickler, Tester, Architekten und Auftraggeber <br />
*Security Management von Anwendungen im Unternehmen <br />
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten <br />
*Anwendungssicherheit und Metriken <br />
*und natürlich an OWASP selbst.<br />
<br />
Es soll keine Hardcore Hacker Veranstaltung sein. Viele werden mit IT-Security konfrontiert und suchen Lösungen für sichere Anwendungen. Technische Themen sind natürlich auch erwünscht. Dafür können wir eigenen Termine auf dem Stammtisch planen.<br />
<br />
===== Der 3. Frankfurter OWASP Stammtisch findet am 21.09.2011 statt =====<br />
<br />
Liebe Freunde von OWASP, <br />
<br />
der Frankfurter OWASP Stammtisch findet wieder statt. Der nächste Termin ist der 21.09.2011. Für das folgende Treffen ist der 23.11.2011 geplant.<br />
<br />
Der 3. OWASP Stammtisch Frankfurt wird wieder in der [http://j.mp/piQdaP Arche Nova, Kasseler Str. 1a, Frankfurt a.M.] stattfinden. <br />
<br />
Bei diesem Treffen steht wieder das Kennenlernen im Vordergrund. Weiter wollen wir uns u.a. darüber unterhalten, welche Themen wir für die nächsten Stammtische planen und ob wir in der Lokation bleiben wollen.<br />
<br />
<br />
Ich bitte um eine kurze Anmeldung auf Doodle [http://www.doodle.com/77m7p3qama2u723z Doodle] damit ich bei Bedarf das Lokal vorwarnen kann.<br />
Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke. <br />
<br />
===== Der 4. Frankfurter OWASP Stammtisch findet am 23.11.2011 statt =====<br />
<br />
==== Stuttgart ====<br />
<br />
===== Der Stammtisch findet jeden ersten Montag jeden zweiten Monat statt. =====<br />
<br />
Wir treffen uns jeweils um 19 Uhr im [http://www.sportpark-neuwirtshaus.de/ Sportrestaurant Neuwirtshaus], Neuwirtshausstrasse 199a 70439 Stuttgart. Wer mit dem ÖPNV anreist (S-Bahn Haltestelle Porsche) kann sich per E-Mail mit der Ankunftszeit melden, es gibt dann einen Fahrdienst &nbsp;:) <br />
<br />
Derzeit sind wir insgesamt rund 10 Personen und freuen uns auf weitere Teilnehmer. Zu jedem Termin wird ein Vortrag zum Besten gegeben, Wünsche jederzeit gerne. Um vorhergehende Anmeldung per [mailto:tobias.glemser@owasp.org E-Mail] wird gebeten, wer das verschwitzt darf aber natürlich auch kommen. Bei Fragen zum Stammtisch einfach kurz anschreiben. <br />
<br />
Der Stammtisch wird hier, über die OWASP-Germany Mailingliste und [https://www.xing.com/profile/Tobias_Glemser Xing] (einfach mit mir verknüpfen) angekündigt. <br />
<br />
Wir freuen uns auf Euer Kommen! <br />
<br />
Tobias <br />
<br />
'''Termine:''' <br />
<br />
*'''10.10.11''' <br />
<br />
:Programm: <br />
:*19.00h Beginn <br />
:*19.30h - t.b.a.<br />
<br />
----<br />
<br />
'''Rückblick '''<br> <br />
*01.08.2011. 10. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Vortrag "Neuerungen in Burp Pro 1.4", Michael Schäfer (Schutzwerk GmbH). Bilder von der Riesenjubiläumsparty im Anschluss müssen leider unter Verschluss gehalten werden. "What happens at Stammtisch, stays at Stammtisch". Achja: Grüße an die Vegas-Reisenden unter uns, die deswegen die Sause verpasst haben :)<br />
*06.06.2011. 9. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzfristige Absagen (unter anderem des Referenten) taten der Stimmung keinen Abbruch. Sehr interessante Diskussionen über Passwortsicherheit, RSA Token Security und anderes.<br />
*04.04.2011. 8. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Der bestbesuchteste Stuttgarter Stammtisch bisher. Die insgesamt 13 Teilnehmer diskutierten über den Vortrag von [http://webuser.hs-furtwangen.de/~doelitz/index.html Frank Dölitzscher] (Hochschule Furtwangen) zu einem Cloud-Frontend mit Single-Sign-On Anbindung und SSH-Key Erstellung [[File:2011-04-04_CloudIA_WebGUI_OWASP_Stammtisch_Stuttgart.pdf|Folien]] interessiert zu. Insbesondere wurden mögliche Schwachstellen der Implementierung der Lösung und des Java-Client zur SSH-Key Erstellung besprochen. Für beide Seiten ein Gewinn :)<br />
<br />
:Antworten von Frank bzgl. der offenen Fragen:<br />
:"- In der Version des Shibb-Idp den wir verwenden ist ein zwingender Restart beim Einlesen einer neuen Config notwendig. Die Konfiguration ist dateibasiert und gliedert sich in 3 Dateien:<br />
<br />
:a) Relying Party - regelt Förderation (Verweis auf MetaData)<br />
:b) MeTaData - Beinhaltet alle SPs mit Links darauf, Metadaten der einzelnen SP<br />
:c) AttributeFilter.xml - Regelt welche Userattribute werden einem SP nach erfolgreicher Autorisierung übermittelt<br />
<br />
:Die kritische Datei ist die AttributeFilter.xml.<br />
:In der aktuellsten Shibboleth Version sollte ein einfacher Reload der Konfigurationen auch prinzipiell möglich sein. Allerdings warnen die Entwickler vor einem Produktiveinsatz: "Caution Do NOT enable configuration reloading in a production environment unless you have a rigorous configuration testing process in place and used."<br />
<br />
: Siehe: https://wiki.shibboleth.net/confluence/display/SHIB2/IdPConfigConfig<br />
<br />
:Unser aktueller Idp wurde inzwischen auf einen größeren Server umgezogen. Ein Restart dauert nun etwa 25 Sekunden. Das ist zwar deutlich schneller als zuvor (1,5min) allerdings für das Cloud-Szenario immer noch nicht praktikabel.<br />
<br />
:Zur Erreichbarkeit der VMs untereinander: Die VMs akzeptieren nur Incoming Traffic vom Reverse-Proxy (SP)."<br />
<br />
:[[Image:2011-04-04-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*07.02.2011. 7. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Kurzdiskussion: "Brauchen wir ein Security-Framework Verwaltungs-Protokoll?"<br />
<br />
*08.11.2010. 6. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Nanu, wieder kein Vortag, aber beschwert hat sich auch niemand :)<br />
<br />
*06.09.2010. 5. OWASP German Chapter Stammtisch Stuttgart <br><br />
:Leider kein Vortrag, aber eine launige Runde. Wer schon immer wissen wollte was Globolis, Pferde und die Goonies mit IT-Security zu tun haben oder wie die Visitenkarte von Kevin Mitnick aussieht, der ist bei uns einfach genau richtig..<br />
<br />
*07.06.2010. 4. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:Neuigkeiten vom Chapter Meeting im Mai 2010 <br />
:Vorstellung und Erfahrungsberichte mit den kommerziellen Tools HP Webinspect (Andy Kurtz) und Acunetix (Tobias Glemser). Keine Folien da "Freestyle". Kurzfazit war: Beide Tools bilden ein ähnliches Featureset ab, um manuelles Testen kommt man niemals rum.<br />
<br />
:[[Image:2010-06-07-owasp-stammtisch-stuttgart.jpg|300px]]<br />
<br />
*12.04.2010. 3. OWASP German Chapter Stammtisch Stuttgart <br><br />
<br />
:[[Media:OWASP_Stammtisch_20100412.ppt|Vortrag "WATOBO - Web Application Toolbox"]] von Andreas Schmidt. Vorstellung eines selbst entwickeltes Werkzeugs ([http://watobo.sf.net WATOBO - Web Application Toolbox]) zur Überpruefung von Webapplikationen. Das Tool selbst ist unter der GNU Public License veröffentlicht und soll Sicherheitsspezialisten bei der Durchführung von semi-automatisierten Sicherheitsanalysen unterstützen.<br />
<br />
*01.02.2010. 2. OWASP German Chapter Stammtisch Stuttgart<br />
<br />
:Vortrag Vorstellung OWASP Whitepaper von Tobias Glemser "[[Best Practice: Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]"<br><br />
<br />
*30.11.2009. 1. OWASP German Chapter Stammtisch Stuttgart<br><br />
<br />
:Das erste Treffen diente dem Beschnuppern und gemeinsamen Pläne schmieden für die nächsten Male<br><br />
<br />
<br> <br />
<br />
==== Düsseldorf ====<br />
<br />
===== Coming soon! =====<br />
<br />
Vorgeschlagen von: Sven Schlüter <br> //TODO <br />
<br />
==== Köln ====<br />
<br />
===== Allgemeines =====<br />
<br />
Der Kölner Stammtisch trifft sich zur Zeit alle zwei Monate. Es ist geplant zwischen Vorträgen und lockeren Diskussionen zu alternieren. Jeder ist herzlich willkommen und kann gerne noch Freunde, Kollegen, Interessierte mitbringen. <br />
<br />
<br> <br />
<br />
===== 7. Kölner OWASP Stammtisch am 24.08.2011 =====<br />
<br />
Wir treffen uns zum siebten Kölner Stammtisch am 24.08.2011 um '''19:00Uhr'''. <br />
<br />
Wegen der Sommerpause im Töller setzen wir unsere Tour durch Kölsche Brauhäuser diesmal in der Neustadt Nord fort.<br />
<br />
Treffpunkt ist diesmal die Schreckenskammer am Ursulakloster (http://www.schreckenskammer.com/). <br />
<br />
Die Schreckenskammer kann man recht schnell vom Bahnhof erreichen und auch mit dem Auto gibt es auf dem Hansaring genügend Parkmöglichkeiten.<br />
<br />
Bitte gebt mir noch eine [mailto:ralf.allar@owasp.org Rückmeldung], falls ihr kommt, damit ich einen Überblick über die Zahl der Anwesenden erhalte. Danke! <br />
<br />
<br />
==== Hamburg ====<br />
<br />
<br />
===== Generelles =====<br />
<br />
Wer und Interesse hat mitzuwirken oder mitgestalten möchte, bitte bei Dirk Wetter melden (dirk punkt wetter aet owasp punkt org). Besonders Vorträge plus Vortragende sind gefragt. Ansonsten werden die Treffen natürlich über die [https://lists.owasp.org/mailman/listinfo/owasp-germany/ OWASP-Deutschland-Liste] angekündigt. <br />
<br />
===== Viertes Treffen am 14.4.2011 =====<br />
<br />
* Vortrag von Tim Sattler: "Sicherheit in der Cloud - Chancen und Risiken". <br ><br />
* Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
* [http://www.guug.de/lokal/hamburg/talks/OWASP_Sicherheit_in_der_Cloud.pdf Slides]<br />
<br />
===== Drittes Treffen am 7.3.2011 =====<br />
<br />
Den Rosenmontag begehen wir im Norden mit einem Konkurrenzprogramm: Gemütlicher OWASP-Abend mit sinnieren über die Websicherheit in <i>Omas Apotheke</i> in der Schanze. Los geht's um 19 Uhr. <br />
<br />
===== Zweites Treffen inkl. Vortrag am 14.10.2010 =====<br />
<br />
VortragsthemaÖ "OWASP Top 10 - Wat nu?" <br />
[http://drwetter.eu/talks/OWASP_T10-Wat-nu.pdf Slides]<br><br />
Datum/Zeit: 14.10.2010, 19 Uhr<br><br />
Ort: Uni RZ in der [http://maps.google.com/maps?f=q&hl=en&q=hamburg,++schlueterstr.+70,+germany&t=h&om=1&ll=53.569861,9.986293&spn=0.010806,0.02296 Schlüterstrasse 70], Seminarraum 304 (3.OG)<br><br />
Vortragender: Dirk Wetter<br><br><br />
<br />
===== Erstes Treffen am 8.7.2010 =====<br />
<br />
Wir treffen uns erstmalig am '''8.7.2010 um 19 Uhr''' auf [http://maps.google.de/maps?q=strandpauli&um=1&ie=UTF-8&sa=N&hl=en&tab=wl Strandpauli], einem der Beachclubs mit Aussicht auf den schönen Hamburger Hafen. Der 8.7. ist der erste Ferientag in HH und fußballfrei. <br> Inhalt des ersten Treffens ist eher ein Informationsaustausch: Neben etwas Networking wäre es prima, Erwartungen zu diskutieren und vielleicht die ersten Vorträge zu planen. Da das in dem Etablissement im Sommer dort wahrscheinlich nicht ganz leer sein wird und der Beachclub sicherlich nicht auf den OWASP-Stammtisch wartet&nbsp;;-) wird wärmstens empfohlen, bis zum 7.7. morgens Dirk Wetter sich anzumelden, der dann die Reservierung vornimmt. Sonst muss man halt stehen.&nbsp;;-) <br />
<br> <br />
Mindestens einer wird ein OWASP-T-Shirt tragen. (Hint: Das Logo ist auch auf dieser Webseite zu finden).<br />
<br />
==== Karlsruhe ====<br />
<br />
===== FINDET STATT!!! - 4. Biertrinken für die Sicherheit am 01.09.2011 =====<br />
<br />
Nachdem sich für das spontane 4. Biertrinken für die Sicherheit in Karlsruhe auf die Einladung auf der Mailing-Liste ein kleiner (aber feiner) Teilnehmerkreis gefunden hat, wird das Treffen am 01.09. um 19:00 Uhr in der Gaststätte [http://www.trompeter-von-saeckingen.com Trompeter von Säckingen] am Mühlburger Tor stattfinden. Das Restaurant ist direkt gegenüber von der Haltestelle Mühlburger Tor, die gefühlt von jeder Straßenbahn in Karlsruhe angefahren wird - die Parkplatzsituation ist in der Gegend nicht so toll. Ich freue mich auf das Wiedersehen und speziell auf den Besuch von Martin in Karlsruhe... <br />
<br />
<br />
===== FÄLLT AUS!!! - 3. Biertrinken für die Sicherheit am 19.05.2011 =====<br />
<br />
'''Achtung: Ausfall''' - wegen zu vieler definitiver Absagen müssen wir den 3. Stammtisch leider ausfallen lassen...<br />
<br />
'''Achtung: Terminverschiebung''' - mangels geeigneter Örtlichkeit muss der geplante 3. Stammtisch am 15.04.2011 in Karlsruhe leider um einen Monat verschoben werden! <br />
<br />
'''Achtung: Ort gefunden!''' Am 19.05. treffen wir uns in der [http://www.pizzeria-karlsruhe.de Pizzeria Da Benito] in Karlsruhe-Neureut ([http://maps.google.com/maps?client=ubuntu&channel=fs&oe=utf-8&ie=UTF8&q=pizzeria+da+benito+karlsruhe&fb=1&hq=pizzeria+da+benito&hnear=Karlsruhe,+Germany&cid=0,0,1758390731419115577&z=16&iwloc=A Rechts der langen Richtstätt 4, 76149 Karlsruhe]). Mit der S1 ist die Pizzeria über die Haltestelle "Welschneureuter Straße" am besten zu erreichen.<br />
<br />
"Aller guten Dinge sind Drei." - unter diesem Motto wollen wir uns (dann jetzt) am '''Donnerstag, 19.05.2011''' wieder um 19:30 in Karlsruhe treffen.<br />
<br />
Beim letzten Mal hatten wir eine tolle "chalk and board"-Diskussion. Bitte bringt auch diesmal wieder gute Ideen hierfür mit:<br />
<br />
* Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kai Jendrian)<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
* Die Bedeutung der Mozilla Firefox CSP (Kai Jendrian)<br />
<br />
Der Schwerpunkt des Karlsruher OWASP-Stammtisches soll immer mehr auf einem Austausch zwischen Entwicklern und Security-Fachleuten dienen, um den [https://twitter.com/johnwilander/status/35037398362492928 "Developers don't know a shit about security"-Vorurteilen] an der Wurzel zu begegnen! Also, schaut über den Tellerrand und verbreitet den Termin auch bei Entwicklern im Raum Karlsruhe!<br />
<br />
<br />
===== 2. Biertrinken für die Sicherheit am 17.02.2011 =====<br />
<br />
8 Wochen nach dem ersten Stammtisch wollen wir uns am '''Donnerstag, 17.02.2011''' wieder um 19:30 in Karlsruhe treffen (Regel: Bis auf weiteres jeder 3. Donnerstag alle 2 Monate). Es ist wieder ein Tisch in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe reserviert.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wie beim ersten Stammtisch abgesprochen soll bei diesem Stammtisch in Form von offenen Diskussionen "gearbeitet" werden. <br />
<br />
Themenvorschläge bisher:<br />
<br />
* Die Rolle von Vertrauen für Sicherheit im Web (Kai Jendrian, Klaus J. Müller)<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
===== 1. Biertrinken für die Sicherheit am 16.12.2010 =====<br />
<br />
Am '''Donnerstag, 16.12.2010''' wird um 19:30 Uhr in Karlsruhe der OWASP-Kick-Off-Stammtisch (Biertrinken für die Sicherheit) in der [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=weinweg1+,+76131+karlsruhe&sll=51.151786,10.415039&sspn=20.252719,44.780273&ie=UTF8&hq=&hnear=Weinweg+1,+Karlsruhe+76131+Karlsruhe,+Baden-W%C3%BCrttemberg&z=16 Gaststätte Schwanen], Weinweg 1a, 76131 Karlsruhe stattfinden.<br />
Mit der Straßenbahn ist der Schwanen am besten über die Haltestelle Forststraße in Rintheim zu erreichen.<br />
<br />
Wir werden uns über OWASP im Allgemeinen und die Zukunft des Karlsruher Stammtisches austauschen.<br />
<br />
Wir freuen uns auf jeden, der vorbei kommt. Bitte vorher kurz bei [mailto:kai.jendrian@owasp.org Kai Jendrian] Bescheid geben.<br />
<br />
==== Nürnberg ====<br />
<br />
===== Erster Stammtisch =====<br />
<br />
Der erste Stammtisch für den Raum Nürnberg, Fürth und Erlangen steht nun. Wir treffen uns das erste mal am Donnerstag dem 9. Dezember 2010 im [http://www.hotel-drei-linden-nuernberg.de/ Hotel/Restaurant drei Linden] in [http://maps.google.de/maps?f=q&source=s_q&hl=de&geocode=&q=%C3%84u%C3%9Fere+Sulzbacher+Stra%C3%9Fe+1-3+%0990489+N%C3%BCrnberg&sll=51.151786,10.415039&sspn=19.031459,44.780273&ie=UTF8&hq=&hnear=%C3%84u%C3%9Fere+Sulzbacher+Stra%C3%9Fe+1,+N%C3%BCrnberg+90489+N%C3%BCrnberg,+Bayern&z=16 Äußere Sulzbacher Straße 1-3, Nürnberg]<br />
<br />
===== Kolloquium =====<br />
<br />
Dieser erste Stammtisch findet im Anschluss an das [http://www.ohm-hochschule.de/institutionen/fakultaeten/informatik/kolloquien/page.html Informatik-Kolloquium] der [http://www.in.ohm-hochschule.de Ohm-Hochschule] statt:<br />
<br />
'''Injection-Angriffe auf Web-Anwendungen''', 17.30 Uhr, Fakultät Informatik, [http://www.in.ohm-hochschule.de/lageplan Hohfederstr. 40, EG rechts, Hörsaal Q 007], das ist ganz in der Nähe der "drei Linden"!<br />
<br />
Es spricht Ralf Reinhardt von der [http://www.sicsec.de sic&#x5B;!&#x5D;sec GmbH], Absolvent des Ohms und Organisator des OWASP Stammtisches München. Veranstalter ist die Fakultät Informatik. Ansprechpartner ist [http://www.in.ohm-hochschule.de/Delfs Prof. Dr. Hans Delfs]. Die Einladung zum Kolloquium richtet sich ebenfalls an alle Interessierte!<br />
<br />
===== Organisatorisches =====<br />
<br />
Damit wir planen können bitte bei [mailto:heiko.richler@owasp.org Heiko Richler] eanmelden. Willkommen ist trotzdem jeder, auch ohne Anmeldung! Wer nur dieses mal nicht kann oder wem Erlangen oder Fürth lieber wären bitte auch melden!<br />
<br />
===== Weitersagen =====<br />
<br />
Bitte diese Info an potentiell Interessierte weiterleiten. Unser Thema ist in erster Linie (Web) Application Security. Man muss dazu überhaupt nichts von OWASP wissen. Es kennen zu lernen schadet aber sicher auch nicht.<br />
<br />
<headertabs /></div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=Germany&diff=113071Germany2011-06-27T08:21:33Z<p>Kai Jendrian: </p>
<hr />
<div>__NOTOC__ <!--<br />
--> <br />
{{Chapter Template|chaptername=Germany<br />
|extra=[[Image:owasp_germany_logo.png|right]]<br />
The chapter leader is [mailto:Georg.Hess@artofdefence.com Georg Heß].<br />
<br />
Chapter Board members are: [mailto:tobias.glemser@owasp.org Tobias Glemser], [mailto:boris@owasp.org Boris Hemkemeier], [mailto:achim@owasp.org Achim Hoffmann], [mailto:ulrike.petersen@owasp.org Uli Petersen], Bruce Sams.<br />
<br />
|mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-germany<br />
|emailarchives=http://lists.owasp.org/pipermail/owasp-germany<br />
}}<br />
<br />
<br /><br />
<br />
==== OWASP Germany ====<br />
=== OWASP Germany ===<br />
<br />
Herzlich Willkommen auf der Homepage des OWASP German Chapter.<br />
<br />
;Aktuelles: Ankündigung des 4. German OWASP Day 2011 am 17.11.2011 in München<br />
<br />
Auch dieses Jahr wird es eine Konferenz des German Chapter geben. Details finden Sie auf der [[German OWASP Day 2011|4. German_OWASP_Day_2011]] Homepage.<br />
<!-- alter Name: AppSec Germany<br />
[[OWASP AppSec Germany 2011 Conference|OWASP AppSec Germany 2011 Conference]]<br />
--><br />
<br />
==== Aktuelles / News ====<br />
<br />
=== Aktuelles / News ===<br />
;Ankündigung: Der 4. German OWASP Day 2011 findet am 17.11.2011 statt, Details finden Sie '''[[German OWASP Day 2011|hier]]'''.<br />
----<br />
*17.11.2011: German OWASP Day 2011<br />
*09.07.2011: Workshop zur Übersetzung der OWASP Top 10 in Karlsruhe (Kontakt: [[User:Kai_Jendrian|.kai]])<br />
*18.06.2011: Webseite mit neuem Layout<br />
*April 2011: Initiierung des German Language Project<br />
*12 October 2009: [[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]] <br />
*10 September 2008: [[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]] <br />
*17 July 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF_v104.en.pdf|Best Practices: Use of Web Application Firewalls (English)]] *18 March 2008: OWASP Germany released [[Media:Best_Practices_Guide_WAF.pdf|Best Practices: Einsatz von Web Application Firewalls (German)]] <br />
*07 September 2007: Chapter meeting in Frankfurt <br />
*18 July 2007: scheduled chapter meeting on September 7th 2007 <br />
*02 Mar 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.bund.de/fachthem/betriebssysteme/indigo/index.htm#indigoen Indigo Security] (engl: 'Indigo Security').<br />
<br />
*23 Feb 2007: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.de/literat/studien/tomcat/index.htm Apache Tomcat Sicherheitsuntersuchung] (engl: 'Apache Tomcat Security Assessment').<br />
<br />
*06 Sept 2006: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [https://www.bsi.bund.de/cae/servlet/contentblob/476464/publicationFile/30632/WebSec_pdf.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] (engl: 'Measures and Best Practices for Web Application Security').<br />
<br />
*20 May 2006: OWASP Moves to MediaWiki Portal<br />
<br />
OWASP is pleased to announce the arrival of OWASP 2.0! <br />
<br />
OWASP 2.0 utilizes the MediaWiki portal to manage and provide the latest OWASP related information. Enjoy! <br />
<br />
<br />
==== Projekte des German Chapter ====<br />
<br />
== Projektierung der Sicherheitsprüfungen von Webanwendungen ==<br />
<br />
'''[[Projektierung der Sicherheitsprüfung von Webanwendungen|Projektierung der Sicherheitsprüfung von Webanwendungen]]'''<br />
<br />
== Best Practices: Web Application Firewalls ==<br />
<br />
'''[[Best Practices: Web Application Firewalls|Best Practices: Web Application Firewalls wiki pages]]'''<br />
<br />
== German Language Project ==<br />
<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
Obwohl die ''lingua franca'' <sup>[1]</sup> in der IT Englisch ist, fragen auch Fachleute immer wieder nach Texten in Deutsch. Für einige (Fach-)Artikel gibt es schon Übersetzungen. Inspiriert durch das [[OWASP Spanish|OWASP Spanish Project]] und [[OWASP Portuguese Language Project|OWASP Portuguese Language Project]] ist die Idee entstanden, wichtige Dokumente usw. auch in Deutsch zur Verfügung zu stellen. Einzelne Ansätze dazu gab es zwar schon, diese und weitere werden jetzt zentral üeber das '''[[OWASP German Language Project|OWASP German Language Project]]''' verwaltet.<br />
<br />
Wir laden alle Interessierte herzlich ein mit Kommentaren und Übersetzungen beizutragen und so wichtige Aspekte der Web Application Security auch in Deutsch zu formulieren, so dass ein noch größeres Publikum erreicht wird.<br />
Weiter Detail findet Ihr auf der [[OWASP German Language Project|Projektseite]]. [[User:Mrohr|Matthias Rohr]], der Project Leader, freut sich über Eure tatkräftige Unterstützung.<br />
----<br />
<small>[1] ''lingua franca'', man sieht an diesem Ausdruck, dass auch die Lateiner wussten, welches die Verkehrssprache ist</small> &#9786;<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
The [[OWASP German Language Project|OWASP German Language Project]] is a new OWASP Project that will provide a foundation, guideance and common terminology for German translations. Please contact [[User:Mrohr|Matthias Rohr]], who is the project leader, if you want to participate. Any comments are welcome ...<br />
|} <br />
<br />
==== OWASP Stammtisch-Initiative ====<br />
=== OWASP Stammtisch-Initiative ===<br />
<br />
{| width="100%" style="background-color:inherit;"<br />
| width="70%" style="vertical-align:top; padding-right:0.5em;" |<br />
In mehren Städten gibt es '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]] ''', bei denen man sich in lockerer Runde im Biergarten oder Gasthaus trifft um sich auszutauschen, nette Leute kennenzulernen oder auch ernsthafte Sicherheitsthemen zu diskutieren. <br />
<br />
Aktive Stammtische gibt es (Stand 2011) in:<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |München]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Köln]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]]<br />
<br />
| width="30%" style="vertical-align:top; padding-left:0.5em;border-left:1px solid black" |<br />
A "regular's table" (Stammtisch) is a German tradition for meeting each other in a beer garden or a pub in order to discuss certain topics (and to drink beer, of course&nbsp;;-).<br />
<br />
In the case of an '''[[OWASP German Chapter Stammtisch Initiative|OWASP-Stammtisch]]''' it's all about Web Application Security. Right now a Stammtisch is established in <br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=M.C3.BCnchen |Munich]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=K.C3.B6ln |Cologne]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Frankfurt |Frankfurt]],<br />
[[OWASP_German_Chapter_Stammtisch_Initiative#tab=Stuttgart |Stuttgart]]<br />
|}<br />
<br />
==== Chapter Meetings ====<br />
<br />
== Chapter Meeting am 20.5.2010 in München ==<br />
<br />
=== Agenda ===<br />
<br />
* 14:00 Allgemeine Begrüßungs- und Vorstellungsrunde <br />
* 14:15 Bruce Sams: „Strategie und Kosten für ein SDLC“ <br />
* 14:50 Diskussion <br />
* 15:10 Boris Hemkemeier: „Two Factors Are Not Enough“ <br />
* 16:05 Diskussion (geht nahtlos über in die) <br />
* 16:15 Kaffeepause <br />
* 16:35 Vortrag mit Diskussion „Organisatorisches im Chapter“ <br />
* 17:15 Beginn der Beschlussfassungen und Wahlen <br />
* 17:25 Vortrag mit Diskussion „OWASP Germany Conferenc 2010“ <br />
<br />
=== Organisatorisches im Chapter === <br />
<br />
Die Wesentlichen Punkte, die umgesetzt oder verbessert werden sollen: <br />
<br />
* Mehr Außenwirkung durch Public Relations, bessere Pressearbeit / Pressemitteilungen und Einführung und Pflege einer Sprecher- und Rednerliste (um z.B. bei öffentlichen Veranstaltungen OWASP adäquat vorstellen zu können) <br />
* Gepflegtes Wiki sowohl für Außendarstellung als auch als Plattform für die interne Kommunikation <br />
* Einführung von direkten Ansprechpartner für diverse Branchen<br />
<br />
Es folgt eine kurze Diskussion, wie dies effektiv umgesetzt werden kann. Es wird ein Vorschlag durch konkludentes Handeln angenommen: Es soll ein Chapter Board bestehend aus 5 Mitgliedern gewählt werden. Jedes dieser Mitglieder bekommt eine oder mehrere dedizierte Aufgabe(n), um die oben genannten Punkte abzudecken und umzusetzen. Es folgt ein Aufruf, sich für eine entsprechende Wahl zur Verfügung zu stellen. Es soll ebenso der neue Chapter Leader gewählt werden. Da sich nur ein Kandidat für nur einen Posten zur Wahl für die nächsten zwei Jahre zur Verfügung stellt, wird folgendes entschieden: Bei Abstimmungen hat jedes Mitglied des Boards genau eine Stimme, während der Chapter Leader zwei Stimmen hat. So soll zukünftig bei Abstimmungen eine Stimmengleichheit verhindert werden. <br />
<br />
=== Beschluss zur Anzahl der Chapter Leaders ===<br />
<br />
Es wird von den 12 Teilnehmern des Chapter Meetings einstimmig beschlossen, das zukünftig das Chapter Germany (analog zu den meisten anderen OWASP Chapters) nur noch einen Chapter Leader hat. <br />
<br />
=== Wahl des Chapter Leaders ===<br />
<br />
'''Georg Heß''' kandidiert als Chapter Leader und wird mit 11 von 12 Stimmen bei einer Enthaltung zum neuen Chapter Leader des OWASP Chapters Germany gewählt. <br />
<br />
=== Beschluss zur zukünftigen Zusammensetzung des Boards ===<br />
<br />
Einstimmig wird beschlossen, dass das zukünftige Board aus 5 Mitgliedern besteht. Diese sollen die Aufgaben wie in der Diskussion beschrieben wahr nehmen. <br />
<br />
=== Wahl des Boards ===<br />
<br />
Es kandidieren '''Tobias Glemser, Boris Hemkemeier, Achim Hoffmann, Uli Petersen und Bruce Sams ''' für die 5 Sitze im Board. Alle werden einstimmig gewählt. <br />
<br />
Alle Gewählten nehmen die Wahl an. <br />
<br />
=== OWASP AppSec 2010 ===<br />
<br />
Es folgt ein kurzer historischer Rückblick der Veranstaltungsorte: 2008 im Hotel in Frankfurt, 2009 auf der Messe it-sa in Nürnberg. Kurze Diskussion pro und contra Hotel vs. Messe vs. Hochschul-Location. <br />
<br />
* Es soll geprüft werden, ob die diesjährige '''„OWASP Germany Conference 2010“''' wieder in Kooperation mit der Messe Nürnberg / it-sa durchgeführt werden kann (z.B. am 20.10.2010). <br />
* Weiterhin ist ein Konferenztag mit '''zwei verschiedenen Tracks (Technik und Management)''' angedacht. <br />
* Um die inhaltliche Gestaltung voranzutreiben wird ein '''Programm-Komitee''' (initial bestehend aus '''Bruce Sams, Kai Jendrian, Boris Hemkemeier und Martin Johns''') ins Leben gerufen, das alsbald den '''CFP''' starten soll.<br />
<br />
Gegen 18:15 löst sich das OWASP German Chapter Meeting auf und geht nahtlos in den 12. „Happy Anniversary!“ OWASP Stammtisch München über. <br />
<br />
== OWASP German Chapter Meeting - February 20th, 2008 in Darmstadt ==<br />
<br />
;Date: February 20th, 2008, 11:00-16:15<br />
;Location: Darmstadt, CAST (http://www.cast-forum.de)'''<br> Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt]<br />
<br />
The next chapter meeting will be hosted at CAST in Darmstadt.<br> This time the focus is on technical presentations and discussion. <br> <br> <br />
<br />
;Agenda: Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion. <br />
*1. (11:00 - 11:15) Welcome, Introduction and Administrativia <br />
*2. (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann) <br />
*3. (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom) <br />
*4. (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Slides: [http://www.owasp.org/images/1/1b/WAF-Paper.pdf PDF]) (Alexander Meisel) <br />
*5. (12:30 - 13:15) Break <br />
*6. (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann) <br />
*7. (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss) <br />
**"Input validation in ASP.NET -- tips, tricks &amp; pitfalls" (Boris Hemkemeier) <br />
**"Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel) <br />
*8. (14:45 - 15:00) Coffee Break <br />
*9. (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias) <br />
*10. (15:45 - 16:00) Wrap-up and outlook<br />
<br />
<br> <br />
<br />
== Chapter Meeting on September 7th 2007 in Frankfurt/Main ==<br />
<br />
After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00. <br />
<br />
This first chapter meeting had as its main goal the re-initiation of the German chapter and to start work on projects. Talks and presentations are secondary and will receive more focus at subsequent meetings. <br />
<br />
'''[https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html Read meeting notes/minutes here]''' <br />
<br />
<br />
==== Past Events ====<br />
<br />
== OWASP AppSec Germany 2010 Conference 20.10.2010 in Nürnberg ==<br />
[[OWASP AppSec Germany 2010 Conference]]<br />
<br />
== OWASP AppSec Germany 2009 Conference 13.10.09, Nürnberg ==<br />
<br />
Die OWASP AppSec Germany 2009 Conference fand am 13.10.09 mit einer Vorabendveranstalung am 12.10.09 in Nürnberg statt.<br>(The OWASP AppSec Germany 2009 conference will be held on October 13, 2009 in Nürnberg)<br />
;Die Vorträge<br />
* Vorstellung des Open Web Application Security Project<br />
* OWASP Education Project<br />
* Praktische Erfahrung mit dem Secure Software Lifecycle<br />
* Sichere Entwicklung und gängige Schwachstellen in eigenentwickelten SAP-Web-Anwendungen<br />
* Adaptive Sicherheit durch Anomalieerkennung<br />
* Design Bugs<br />
* JavaScript aus der Hölle - advanced client side injection techniques of tomorrow<br />
* Projektierung der Sicherheitsprüfung von Webanwendungenen<br />
* Pentestvorbereitung: Sitemap für Webanwendungen (Tools)<br />
<br />
== OWASP German Chapter Meeting 10.07.2009, Mannheim ==<br />
<br />
;Summary:We will start with three interesting fresh talks. The following topics are the next activities of the OWASP German Chapter: the new [http://www.owasp.org/index.php/OWASP_German_Chapter_Stammtisch_Initiative "Stammtisch Initiative"] and the planning of the [http://www.owasp.org/index.php/OWASP_AppSec_Germany_2009_Conference OWASP AppSec Germany 2009] at Nuremberg. <br />
<br />
;Location:Aula of the [http://www.hs-mannheim.de Hochschule Mannheim], Building 3, Paul-Wittsack-Strasse 10, Mannheim ([http://maps.google.de/maps?f=d&source=s_d&saddr=Mannheim+Hbf&daddr=49.471303,8.48372&geocode=Fbr-8gIduTmBAA%3B&hl=de&mra=dme&mrcr=0&mrsp=1&sz=15&sll=49.474885,8.474715&sspn=0.015532,0.050254&ie=UTF8&z=15 Google Maps]). Please download the [http://www.hs-mannheim.de/campus/grafik/campusplan_legende_web.pdf campus map]. <br />
<br />
;Agenda:<br />
<br />
* 12:00 - 13:00&nbsp;: Lunch (optional, please send an email to [mailto:Georg.Hess@artofdefence.com?subject=OWASP%20Chapter%20Meeting%20Lunch%20registration Georg Heß] to register for lunch), meeting point for the lunch is at the Aula in Building 3<br />
* 13:15 - 13:30 : Opening by our host Prof. Rainer Gerten (German) <br />
* 13:30 - 14:30 : OWASP Educational Services - Teaching Security!, Martin Knobloch, Member of OWASP Global Education Committee (English) <br />
* 14:30 - 15:00 : Vorstellung und aktueller Stand des OWASP Germany Projekts "Best Practice: Projektierung von Sicherheitsprüfungen von Web Applikationen", N.N., Projekt-Mitarbeiter (German) <br />
* 15:00 - 15:45 : Cloud Application Security - Chancen und Risiken - Einige Ansatzpunkte zum Thema, Georg Hess (German) <br />
* 15:45 - 16:15 : Coffee <br />
* 16:15 - 17:00 : Organisational topics of the OWASP German Chapter (German) <br />
** OWASP Stammtisch Initiative <br />
** Outlook and organisational tasks for the 2nd [[OWASP Germany 2009 Conference]]<br />
* nach 17:00 : Come together (Any ideas for a near pub??) <br />
<br />
;Minutes: [https://lists.owasp.org/pipermail/owasp-germany/2009-July/000086.html See the list archive for the minutes.]<br />
<br />
== Wir sind auf der SYSTEMS 08 in München ==<br />
<br />
Besuchen Sie uns vom 21.10. - 24.10.08 in der <br />
<br />
:'''IT-SecurityArea - Halle B3, Stand 228'''<br />
<br />
== OWASP Germany 2008 Conference 25.11.08 in Frankfurt ==<br />
<br />
Die [[OWASP Germany 2008 Conference]] wird am 25.11.08 mit einer Vorabendveranstalung am 24.11.08 in Frankfurt stattfinden. <br />
(The OWASP Germany 2008 conference will be held on November 25, 2008 in Frankfurt.) <br />
<br />
<br />
==== Comments ====<br />
=== Comments ===<br />
If you want to participate in the work of the German OWASP chapter or offer to submit work to it and cannot attend the meeting, please contact any of the German Chapter Board members (see above) or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list]. <br />
<br />
==== Press Relations ====<br />
=== Press Relations ===<br />
Press Relations of the OWASP German Chapter are currently directed exclusively towards the local press. We therefore do not provide english translations. . <br />
<br />
*[http://www.owasp.org/index.php?title=Germany/press Press relations]<br />
<br />
<headertabs /><br />
<br />
[[Category:Germany]]<br />
[[Category:Europe]]</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=113070User:Kai Jendrian2011-06-27T08:19:50Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai.jendrian@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 15 years of Network and Application operations and secuirty<br />
* over 6 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee</div>Kai Jendrianhttps://wiki.owasp.org/index.php?title=User:Kai_Jendrian&diff=113069User:Kai Jendrian2011-06-27T08:19:34Z<p>Kai Jendrian: </p>
<hr />
<div>Kai Jendrian's [profile], [mailto:kai.jendrian@owasp.org email address] and and [[:Special:Contributions/Kai_Jendrian|wiki contributions]].<br />
<br />
=== Expierence ===<br />
* 15 years of Network and Application operations and secuirty<br />
* over 6 years of expierence as security consultant (application security and ISMS)<br />
<br />
=== Day Job ===<br />
* Secorvo Security Consulting GmbH, Karlsruhe, Security Consultant<br />
* main focus: Application Security and Security Management<br />
* based in Karlsruhe (Germany)<br />
<br />
=== OWASP Constributions and Activities ===<br />
* Member German Chapter<br />
* OWASP Stammtisch Karlsruhe<br />
* OWASP AppSec Germany Program Committee<br />
<br />
last revised 3/5/2011</div>Kai Jendrian