OWASP - User contributions [en]

Alexander Meisel (OWASP Germany)

2013-03-28T09:22:53Z

AlexanderMeisel: Adding speaker engagement + some rewording

'''Alexander Meisel (OWASP Germany, OWASP AppSec US ’08 speaker, OWASP AppSec Asia '08 speaker, OWASP AppSec Germany '10 speaker, OWASP AppSec DC '12 speaker)'''

A member of OWASP Germany, Alexander Meisel was CTO and co-founder of 'art of defence'. He currently is charge of the development for the web application firewall product at Riverbed.

His interest and expertise in the area of security dates back to his thesis in which he wrote about avoiding and tracing distributed denial-of-service attacks. He worked for a Swiss IT service provider as a Web security expert; later he joined LINX, Europe’s largest Internet exchange, where he took care of member network security issues while working on the topic of dDoS attacks on a carrier and provider level. After working for three years as a senior consultant designing and implementing large Web farms, including security audits with a leading traffic management company, Alexander switched to the SPX Corporation, where he was the main project manager for Web application solutions in the SAP area. In 2005 he founded 'art of defence' in Germany and developed a truly distributed web application firewall product for high performance environments. The company has been acquired in 2011 by Zeus Technology which has shortly after been acquired by Riverbed Technology.

Alex is one of the major contributors to OWASP’s whitepaper “Best Practices Guide: Web Application Firewalls,” which was released by the OWASP Germany Chapter has been translated into English, French, and Chinese. He is a regular speaker at OWASP conferences and meetings world wide mostly with a focus on web application security, scalability and performance.

Alexander Meisel (OWASP Germany)

2012-03-21T11:42:16Z

AlexanderMeisel:

'''Alexander Meisel (OWASP Germany, OWASP AppSec US ’08 speaker, OWASP AppSec Asia '08 speaker, OWASP AppSec Germany '10 speaker)'''

A member of OWASP Germany, Alexander Meisel was CTO and co-founder of 'art of defence'. He currently is charge of the development for the web application firewall product at Riverbed.

His interest and expertise in the area of security dates back to his thesis in which he wrote about avoiding and tracing distributed denial-of-service attacks. He worked for a Swiss IT service provider as a Web security expert; later he joined LINX, Europe’s largest Internet exchange, where he took care of member network security issues. After working for three years as a senior consultant designing and implementing large Web farms, including security audits with a leading traffic management company, Alexander switched to the SPX Corporation, where he was the main project manager for Web application solutions in the SAP area. In 2005 he founded 'art of defence' in Germany and developed a truly distributed web application firewall product for high performance environments. The company has been acquired in 2011 by Zeus Technology which has shortly after been acquired by Riverbed Technology.

Alex is one of the major contributors to OWASP’s whitepaper “Best Practices Guide: Web Application Firewalls,” which was released by the OWASP Germany Chapter has been translated into English, French, and Chinese. He is a regular speaker at OWASP conferences and meetings world wide mostly with a focus on web application security, scalability and performance.

Alexander Meisel (OWASP Germany)

2012-03-21T11:41:56Z

AlexanderMeisel:

'''Alexander Meisel (OWASP Germany, OWASP AppSec US ’08 speaker, OWASP AppSec Asia '08, OWASP AppSec Germany '10)'''

A member of OWASP Germany, Alexander Meisel was CTO and co-founder of 'art of defence'. He currently is charge of the development for the web application firewall product at Riverbed.

His interest and expertise in the area of security dates back to his thesis in which he wrote about avoiding and tracing distributed denial-of-service attacks. He worked for a Swiss IT service provider as a Web security expert; later he joined LINX, Europe’s largest Internet exchange, where he took care of member network security issues. After working for three years as a senior consultant designing and implementing large Web farms, including security audits with a leading traffic management company, Alexander switched to the SPX Corporation, where he was the main project manager for Web application solutions in the SAP area. In 2005 he founded 'art of defence' in Germany and developed a truly distributed web application firewall product for high performance environments. The company has been acquired in 2011 by Zeus Technology which has shortly after been acquired by Riverbed Technology.

Alex is one of the major contributors to OWASP’s whitepaper “Best Practices Guide: Web Application Firewalls,” which was released by the OWASP Germany Chapter has been translated into English, French, and Chinese. He is a regular speaker at OWASP conferences and meetings world wide mostly with a focus on web application security, scalability and performance.

Alexander Meisel (OWASP Germany)

2012-03-21T11:40:23Z

AlexanderMeisel: Update for OWASP DC 2012

'''Alexander Meisel (OWASP Germany, OWASP AppSec US ’08 speaker)'''

A member of OWASP Germany, Alexander Meisel was CTO and co-founder of 'art of defence'. He currently is charge of the development for the web application firewall product at Riverbed.

His interest and expertise in the area of security dates back to his thesis in which he wrote about avoiding and tracing distributed denial-of-service attacks. He worked for a Swiss IT service provider as a Web security expert; later he joined LINX, Europe’s largest Internet exchange, where he took care of member network security issues. After working for three years as a senior consultant designing and implementing large Web farms, including security audits with a leading traffic management company, Alexander switched to the SPX Corporation, where he was the main project manager for Web application solutions in the SAP area. In 2005 he founded 'art of defence' in Germany and developed a truly distributed web application firewall product for high performance environments. The company has been acquired in 2011 by Zeus Technology which has shortly after been acquired by Riverbed Technology.

Alex is one of the major contributors to OWASP’s whitepaper “Best Practices Guide: Web Application Firewalls,” which was released by the OWASP Germany Chapter has been translated into English, French, and Chinese. He is a regular speaker at OWASP conferences and meetings world wide mostly with a focus on web application security, scalability and performance.

Summit 2011/Open letter to WebAppSec Tool and Services vendors: Release your schemas and allow automation

2011-02-03T08:12:57Z

AlexanderMeisel: /* Vendors that commit to deliver the requested materials */

__TOC__ 
'''IMPORTANT DISCLAIMER: THIS LETTER IS NOT AN OFFICIAL OWASP POSITION. THE OWNERSHIP OF ITS REQUEST BELONGS TO THE NAMES UNDER THE 'SIGNED BY' SECTION'''
 
{{:Summit_2011/Open_letter_to_WebAppSec_Tool_and_Services_vendors:_Release_your_schemas_and_allow_automation/Letter_Content}}
 
==Signed by==
* Dinis Cruz - Application Security Consultant - Independent
* Sebastien Deleersnyder - Managing Technical Consultant - SAIT Zenitel
* Jim Manico - CEO - Infrared Security
* Alexander Meisel - CTO - art of defence

Please use the format: {Name - Role - Company}

==Vendors that commit to deliver the requested materials==
* art of defence

Summit 2011/Open letter to WebAppSec Tool and Services vendors: Release your schemas and allow automation

2011-02-03T08:12:31Z

AlexanderMeisel: /* Signed by */

Summit 2011/Open letter to WebAppSec Tool and Services vendors: Release your schemas and allow automation

2011-02-03T08:12:07Z

AlexanderMeisel: /* Signed by */

__TOC__ 
'''IMPORTANT DISCLAIMER: THIS LETTER IS NOT AN OFFICIAL OWASP POSITION. THE OWNERSHIP OF ITS REQUEST BELONGS TO THE NAMES UNDER THE 'SIGNED BY' SECTION'''
 
{{:Summit_2011/Open_letter_to_WebAppSec_Tool_and_Services_vendors:_Release_your_schemas_and_allow_automation/Letter_Content}}
 
==Signed by==
* Dinis Cruz - Application Security Consultant - Independent
* Sebastien Deleersnyder - Managing Technical Consultant - SAIT Zenitel
* Jim Manico - CEO - Infrared Security
* Alexander Meisel - CTO - art of defence

Please use the format: {Name - Role - Company}
* Alexander Meisel - CTO - art of defence

==Vendors that commit to deliver the requested materials==
* TDB

OWASP AppSec Germany 2010 Conference

2010-10-25T09:37:54Z

AlexanderMeisel: /* Download der Vorträge */

__NOTOC__ 

[[Image:Appsec germany 2010.png|center]] 
<center style="font-size:150%;float:center">Die führende deutsche Konferenz zur Web Application Security in Nürnberg. [https://owasp.artofdefence.com Melden] Sie sich noch heute an.</center> 

==== OWASP AppSec Germany 2010 ====

[[Image:Appsec germany 2010.png|right|190x71px]] Langsam wird es zur (erfreulichen) Gewohnheit: Wie die letzten zwei Jahre wird auch dieses Jahr in Deutschland eine OWASP-Konferenz stattfinden.
<center> </center>

== Sponsoren ==

Wir danken unseren Sponsoren:

{{Template:OWASP_Germany_2010_Sponsors}}

 

== Konferenzdaten ==

Die Konferenz findet parallel zur it-sa (http://www.it-sa.de/) in Nürnberg statt. Als Teilnehmer der OWASP AppSec Germany 2010 haben Sie an allen Tagen freien Eintritt zur it-sa. Mit Ihrer Anmeldung erhalten Sie von uns die entsprechende eGastticket-Nummer, um sich auch dort zu registrieren.

 

=== Wo? ===

CCN Ost CongressCenter

Messezentrum

90471 Nürnberg

 

=== Wann? ===

Vorabendveranstaltung: 19.10.2010

Konferenz: 20.10.2010

 

 

== Organisation ==

*Georg Hess (Chapter Leader Germany)
*Boris Hemkemeier (Board Member)
*Tobias Glemser (Board Member)
*Bruce Sams (Board Member)
*Achim Hoffmann (Board Member)
*Ulrike Petersen (Board Member)
*Kai Jendrian (Program Committee)
*Martin Johns (Program Committee)
*Dirk Wetter (Program Committee)

'''Looking forward to see you in Nuremberg!'''

 

==== Agenda / Presentations ====

Die Agenda für die OWASP AppSec Germany 2010:

== Agenda ==

{| border="0" align="center" style="width: 80%;" class="FCK__ShowTableBorders"
|-
| align="center" style="background: none repeat scroll 0% 0% rgb(64, 88, 160); color: white;" colspan="4" | '''20. Oktober 2010'''
 

|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 
| style="width: 44%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Track 1 - Raum 1
| style="width: 44%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Track 2 - Raum 2
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 09:00 - 9:15
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Begrüßung
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 09:15 - 10:15
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | Keynote -- ''Sebastian Klipper'' Risikofaktor Mensch: Die Suche nach Kompetenz auf OSI-Layer 8
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:15 - 11:00
| align="center" style="width: 80%; background: none repeat scroll 0% 0% rgb(252, 252, 150);" colspan="3" | ''Tom Brennan'' [http://www.owasp.org/images/9/97/Brennan-Keynote.pdf Current State of OWASP Adoption]
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:00 - 11:30
| align="left" style="background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Kaffeepause
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:30 - 12:00
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Der OWASP ASVS Standard, ''Matthias Rohr'' 
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | XML-Security - Brief introduction in the use of web service In B2B environments and backend integration, ''Sascha Herzog''

|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 12:00 - 12:30
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Developing Secure Applications with OWASP, ''Martin Knobloch''
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Seitenkanalschwachstellen im Web erkennen und verhindern, ''Sebastian Schinzel''
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 12:30 - 14:00
| align="left" style="background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Mittagspause
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:00 - 14:30
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | OWASP Top 10, die Vierte: Was t/nun? '' Dr. Dirk Wetter''
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Härtung von SAP HTTP- und Webservices, ''Frederik Weidemann''
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:30 - 15:00
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Sicherheit von Webanwendungen als Massnahme zum Schutz personenbezogenener Daten - ein Entwurf für TOP10 des Datenschutzes, ''Dr. Ingo Hanke'' und ''Daniel Bartschies''
| align="left" style="width: 44%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | WATOBO - Web Application Toolbox, ''Andreas Schmidt'' 
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:00 - 15:30
| align="left" style="background: none repeat scroll 0% 0% rgb(194, 194, 194);" colspan="3" | Pause
|-
| style="width: 12%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:30 - 16:30
| align="center" style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" colspan="3" | distributed Web Application Firewall (dWAF) die Applikation als neuer Security Perimeter (auch in der Cloud), ''Alexander Meisel''
 (Und Abschlussworte)

|}

 

== Download der Vorträge ==

Die Vorträge werden hier nach der Konferenz zum Download bereitstehen ...

{| border="0" align="center" style="width: 80%;" class="FCK__ShowTableBorders"
|-
| style="width: 49%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | Track 1
| style="width: 49%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | Track 2
|-
| colspan="2" style="background: none repeat scroll 0% 0% rgb(242, 242, 242);" align="center" | [[Media:AppSec2010-Keynote.pdf|Keynote]]
|-
|colspan="2" style="background: none repeat scroll 0% 0% rgb(252, 252, 150);" align="center" | [[Media:AppSecGermany210-Brennan-Keynote.pdf|Current State of OWASP Adoption]]
|-
| style="width: 49%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Media:OWASP-ASVS-Standard.pdf|OWASP ASVS-Standard]]
| style="width: 49%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Media:XML_Exteral_Entity_Attack.pdf|XML Exteral Entity Attack (XEE)]]
|-
| style="width: 49%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Media:Developing_Secure_Applications_with_OWASP.pdf|Developing Secure Applications with OWASP]]
| style="width: 49%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Media:Side_Channel_Vulnerabilities.pdf|Seitenkanalschwachstellen im Web erkennen und verhindern]]
|-
| style="width: 49%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Media:OWASP_Top10-Wat-nu.pdf|OWASP Top10 - Wat nu?]]
| style="width: 49%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Media:--comming-soon--.pdf|Härtung von SAP HTTP- und Webservices]]
|-
| style="width: 49%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Media:Datenschutz-Top10.pdf|Schutz personenbezogenener Daten - ein Entwurf für TOP10 des Datenschutzes]]
| style="width: 49%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Media:WATOBO.pdf|Web Application Toolbox]]
|-
|colspan="2" style="background: none repeat scroll 0% 0% rgb(252, 252, 150);" align="center" | [[Media:OWASP-Germany-AppSec2010.pdf|distributed Web Application Firewall (dWAF)]]
|}

== Details zu den Vorträgen ==

=== ''Keynote:'' Sebastian Klipper — Risikofaktor Mensch: Die Suche nach Kompetenz auf OSI-Layer 8 ===

Risikofaktor Mensch: Die Suche nach Kompetenz auf OSI-Layer 8

Unterschiedliche Akteure in Unternehmen und Behörden erleben unterschiedliche Realitäten. Bei Sicherheitsmaßnahmen sind die Abweichungen zwischen Mitarbeitern, Chefs und Fachleuten besonders groß.

Fehlt die Kompetenz '''auf''' oder fehlt sie '''für''' OSI-Layer 8?

=== [http://www.owasp.org/index.php/User:Brennan Tom Brennan] — Current State of Application Security Adoption ===

(Englischer Vortrag): Web application security is critically important - today 75% of attacks are clearly targeting your web applications. In this rapidly evolving landscape professionals - developers, IT, management and information security - all have an important part in web application security.

Founded in 2001, Tom Brennan will provide a review, refresh and update about the OWASP Foundation including the who, what and how we can help.

 

=== Matthias Rohr — Der OWASP ASVS-Standard ===

In diesem Vortrag soll der OWASP ASVS-Standard vorgestellt werden, der erste offizielle Standard der OWASP. Das primäre Ziel des OWASP ASVS-Projektes ist es, die Durchführung von Sicherheitstests für Webanwendungen mittels eines kommerziell einsetzbaren und offenen Standards zu harmonisieren. Der Standard definiert hierzu insgesamt 121 Anforderungen für die Verifikation der anwendungsseitigen Sicherheit einer Webanwendung, die auf vier Prüfstufen („Level“) abgebildet werden.

Als Beispiel werden in Level 1 Anforderungen für die Durchführung automatisierter Prüfungen auf Basis von Web Scannern oder Sourcecodeanalyse-Tools beschrieben. Für das Erreichen von Level 2 werden Anweisungen auf Basis für Code Reviews und Pentests definiert, usw. Dieser Standard lässt sich für die Beauftragung von Sicherheitstests genauso einsetzen, wie als Metrik zur Abnahme solcher Prüfungen und natürlich auch als Richtlinie für deren Implementierung.

 

=== Sascha Herzog — XML-Security - Brief introduction in the use of web service In B2B environments and backend integration ===

* Brief introduction into XML, DTD and XML Schema
* Show attacks against XML generators and XML parsers.
* Presents how the xerces parsers can be hardened to prevent of attacks
* I will talk about XEE xml external entity attacks and flavors of it
* You will get an idea of XML DoS attacks
* Free Hands-on labs include excercises for...
* XML Injection
* XML URL enumeration
* XML directore traversal
* XML port scanning
* All of'em are XXE
 



=== Alexander Meisel — distributed Web Application Firewall (dWAF) die Applikation als neuer Security Perimeter (auch in der Cloud) ===

Als Folge der andauernden Virtualisierung von Diensten und Anwendungen wird es zunehmend schwieriger Applikationen 'einfach' gegen Angriffe abzusichern. Da zentrale Firewalls ohnehin schon wenig gegen Angriffe auf Applikationsebene ausrichten können wird es nicht einfacher Applikationen in virtuellen Umgebungen zu schützen.

Vorsorge bei Entwicklung und Deployment helfen bedingt bei Problemen mit der Sicherheit in einer Applikation an sich. Wie allgemein in der OWASP Community bekannt, gibt es nicht immer Zugriff auf den Source-Code und Patchzyklen in professionellen Umgebungen sind selten unter 2 Wochen zu bewerkstelligen. Web Application Firewalls sind durchaus in der Lage Applikationen sicherer zu machen und bei können einige Problem auch ganz beseitigen. Gegen diese scheinbar gute Lösung gibt es aber dennoch Argumente aus dem Lager der Firewall-Verfechter selbst. Firewalls sind meist Hardware, teilweise virtuelle Hardware, können selten geclustert werden und sind recht unflexibel was Performance anbelangt.

Jeder der es bis jetzt, trotz Virtualisierungsprojekt in der eigenen Firma, geschafft hat Netzwerkverkehr durch eine Hardware Firewall oder Web Application Firewall zu leiten wird sicher bei Cloud-Szenarien daran scheitern. Bei Einsatz von Cloud-Technologien (egal ob 'public' oder 'private' Cloud) kann Application-Security nur noch im näheren Umfeld der virtuellen Maschinen oder auf den virtuellen Maschinen selbst umgesetzt werden (gilt nur für IaaS). Das Konzept der distributed Web Application Firewall (kurz dWAF) bietet hier entschiedene Vorteile. Dieser Vortrag erläutert im wesentlichen den Aufbau und die Funktion dieser Technologie. Anhand von Beispielen wird gezeigt wie diese neue Technologie eingesetzt werden kann um einfach und effizient von einer klassisch selbst gehosteten Applikation, über den ersten Schritt Virtualisierung, zu Cloud Szenarien (public, private, hybird, SaaS, PaaS) migrieren kann.

 

=== Martin Knobloch — Developing Secure Applications with OWASP ===

After an introduction about OWASP, Martin will higlight the top projects of OWASP During the presentation Martin does explain how OWASP material can be used to raise awareness about secure appliation development and how OWASP material does fit into a (secure) development lifecycle.

 

=== Dr. Dirk Wetter — OWASP Top 10, die Vierte: Was t/nun? ===

Vor einem halben Jahr ist mit der 2010er Ausgabe die vierte Ausgabe der OWASP Top 10 erschienen. Abgesehen von der verbesserten Struktur des Werkes erscheinen auf den ersten Blick scheinen die Änderungen zu der Vorversion von 2007 nur marginal. Bei näherem Hinschauen jedoch eröffnen sich eine Menge feiner und wichtiger Unterschiede, wie zum Beispiel die Möglichkeit zum Riskomanagement auf technischer und Managementebene.

Der Vortrag wird die Unterschiede der OWASP Top 10 2010 zu den vorangegangen Versionen beleuchten, kritisch einzelne Punkte hinterfragen und mit ähnlichen Werken, die dieses Jahr erschienen sind, vergleichen, wie der WASC Threat Classification und CWE/Sans Top 25.

 

=== Sebastian Schinzel — Seitenkanalschwachstellen im Web erkennen und verhindern ===

Die sichere Entwicklung von Web-Anwendungen ist mittlerweile erschöpfend dokumentiert und es gibt eine Vielzahl von freien Entwicklungsbibliotheken für praktisch jede Sicherheitsfunktionalität. Daher gibt es für Entwickler keine plausiblen Ausreden mehr dafür, Web-Anwendungen mit kritischen Sicherheitsschwachstellen zu entwickeln. Sicherlich gibt es nach wie vor viel zu viele anfällige Web-Anwendungen. Eine zunehmende Zahl von Web-Anwendungen hält Sicherheitsprüfungen jedoch stand und sind somit nicht trivial kompromittierter. Sind die Daten hinter einer Web-Anwendung ohne die gängigen Web-Schwachstellen, z.B. aus der OWASP Top 10, aber wirklich absolut sicher?

Hier kommen Seitenkanalanalysen ins Spiel, die bereits im Bereich der Kryptoanalyse gut erforscht sind. Dabei misst der Angreifer bestimmte Merkmale seines Ziels, die mit bloßem Auge nicht erkennbar sind. Merkmale können z.B. kleine Unterschiede in der Antwortszeit der Web-Anwendung sein, oder auch versteckte Änderungen im Inhalt der Antwort. Korreliert ein Merkmal mit den Daten im Backend, so kann der Angreifer anhand der Merkmale auf die Daten im Backend schließen. Diese Art der Angriffe im Web sind seit einigen Jahren wissenschaftlich dokumentiert, jedoch in der Entwicklergemeinde noch nahezu unbekannt.

In diesem Vortrag zeige ich an konkreten Beispielen, welche Arten von Seitenkanälen in Web-Anwendungen existieren können, wie man Anwendungen auf Seitenkanäle überprüfen kann und - vor allem - wie man Seitenkanäle in Web-Anwendungen verhindern kann.

 

=== Andreas Schmidt — WATOBO - Web Application Toolbox ===

Die manuelle Penetration von Web-Applikationen ist sehr zeitaufwendig und kann teilweise auch langweilig oder gar frustrierend sein. Auf der anderen Seite weiss man beim Einsatz von automatisierten Werkzeugen nicht so recht wie und was bzw. was nicht geprüft wurde. Beide Ansätze haben ihre Vor- und Nachteile. Allerdings ist die Auswahl an Werkzeugen, die beide Welten vereinen sehr begrenzt.

In dieser Präsentation wird das Werkzeug WATOBO (Web Application Toolbox) vorgestellt, welches beide Ansätze verbindet. WATOBO funktioniert wie ein lokaler Proxy und analysiert den Verkehr bereits ‘on the fly’. Dabei werden schon bei der „Begehung“ einer Applikation hilfreiche Informationen extrahiert und erste Schwachstellen identifiziert. Darüber hinaus besitzt WATOBO automatisierte Tests, wie beispielsweise zur Erkennung von SQL-Injection-, XSS-Schwachstellen und vielen mehr. Zur Zeit ist es das einzige Open-Source-Werkzeug, welches ein ausgeklügeltes Session-Management unterstützt.

WATOBO ist in (FX)Ruby entwickelt und unterstützt die gängigsten Betriebssysteme, wie Windows, Linux und Mac OS. WATOBO wurde im Mai 2010 als Open-Source-Projekt veröffentlicht (http://watobo.sourceforge.net).

Die Präsentation gibt einen Überblick über das Design von WATOBO, die Funktionsweise sowie die Erweiterungsmöglichkeiten. Abgerundet wird die Präsentation durch eine kurze Demonstration.

 

=== Frederik Weidemann — Härtung von SAP HTTP- und Web Services ===

Ausgehend von dem gängigen Szenario, bei dem eine Firma bestehende SAP-Anwendungen in Web Services konvertieren möchte, sollen in dem Vortrag die typischen Risiken bei der Einrichtung von HTTP und Web Services auf dem SAP Web Application Server (SAP WebAS ABAP) aufgezeigt werden. Dabei werden die von SAP bereits mitgelieferten Sicherheitsfunktionen mit einbezogen: Was muss bei SAP explizit programmiert werden, was kann konfiguriert werden?

Nach einer Kurzeinführung über die Historie der Webentwicklung in SAP (ITS, ICF und ICM) wird aufgezeigt

*wie eine sichere Landschaft aussieht und welcher Schutz auf Netzwerkebene angeboten wird
*welche Rolle Web Application Firewalls und Reverse Proxies spielen

Danach wird auf die initiale sichere Konfiguration des SAP WebAS übergeleitet und auf die folgenden Fragen eingegangen:

*Welche Dienste sind standardmäßig aktiviert und sollten deaktiviert werden?
*Welche Sicherungsmaßnahmen bietet SAP bei der Authentifizierung und welche Konsequenzen entstehen aus den einzelnen Authentifikationsmethoden? (SSO, Basic Auth, Zertifikate, …)
*Welche Möglichkeiten existieren auf Konfigurationsebene, um bei HTTP Fehlern zu reagieren? Sie müssen also nicht programmiert werden.
*Welche Form der Protokollierung existiert und welche Probleme treten in der Verbindung mit Reverse Proxies auf?
*Welche Daten werden im Security Audit Log gespeichert und wo findet man die HTTP logs?

Abschließend wird der Fokus auf die Entwicklung von eigenen HTTP Handlern und Web Services gelegt.

*Welche Risiken entstehen und muss man beachten, wenn man bestehende Anwendungen über einen Web Service freigibt?
*Übersicht über SAPs Web Security Szenarios
*Risiken bei der Entwicklung von eigenen HTTP Handlern
*Programmierfehler in Web Service Eigenentwicklungen – Abgleich zur Owasp Top 10

 

=== Dr. Ingo Hanke and Daniel Bartschies — Sicherheit von Webanwendungen als Massnahme zum Schutz personenbezogenener Daten - ein Entwurf für TOP10 des Datenschutzes ===

Am Ausgangspunkt des Interesses an der Sicherheit ihrer Webapplikationen stehen insbesondere für kleine und mittlere Betriebe (KMU) immer häufiger Fragen des Datenschutzes. Ursache dafür ist das verstärkte Interesse der Öffentlichkeit und von Einzelpersonen an Fragen des Schutzes der persönlichen Daten sowie immer weiter verschärfte gesetzliche Vorgaben im Datenschutz.

Dies hat uns dazu bewogen, einen Massnahmenkatalog zur Datensicherheit unter dem Aspekt des Datenschutzes zu entwerfen. Als Basis dienten uns dazu der OWASP-Top10-Katalog zur Datensicherheit von Webapplikationen, unsere eigenen Erfahrungen aus diversen Projekten sowie die Auswertung von datenschutz-relevanten Sicherheitsvorfällen vergangener Jahre.

Ziel dieses Kataloges ist es, das für viele Websitebetreiber aus dem Bereich der KMU eher "abstrakte" und vielfach gerne vernachlässigte Thema der Sicherheit von Webanwendungen in der Agenda ihrer IT-Sicherheit nach oben zu bringen - weil die Relevanz von Sicherheitsvorfällen im Bereich des Datenschutzes selbsterklärend und augenscheinlich ist.

Aus unserer Sicht steht die fehlende oder unsachgemäße Verschlüsselung von Daten bzw. des Datenverkehrs an oberster Stelle - vergleichbar der Position 7 der aktuellen OWASP Top10 "Insecure Cryptographic Storage". Neben der Unkenntnis der Problemlage befinden sich dabei häufig Fragen der Usability und der einfachen Administration personenbezogener Daten in Opposition zu Fragen der Sicherheit.

An Position 2 haben wir fehlendes oder schlechtes Rechtemanagement bei Content-Management-Systemen und fehlende oder fehlerhafte Kontrollmechanismen bei der Publikation von - gegebenenfalls eben vertraulichen - Daten gesetzt. Nicht selten werden schutzwürdige Inhalte von Mitarbeitern veröffentlicht, ohne dass dabei im eigentlichen Sinne technische Sicherheitsmängel vorgelegen haben. Vielmehr sind in diesen Fällen die IT-Sicherheitsrichtlinien mangelhaft.

 

====   Anmeldung ====

Die Anmeldung zur OWASP ist nun online.

== Preise ==

Für die OWASP AppSec 2010 gelten die folgenden Preise:

*normaler Teilnehmer = 229,00 EUR
*OWASP-Mitglied = 169,00 EUR
*Studenten, Beschäftigte von Universitäten, Behörden, öffentlicher Verwaltung etc = 39 EUR (**)

(**) Ein gültiger Studenten- oder Hausausweis o.ä. ist bei der Registrierung vor Ort vorzulegen.

== Anmeldeseite ==

Die Anmeldung zur OWASP AppSec 2010 erfolgt über die folgende Seite:

https://owasp.artofdefence.com/

 

==== Vorabendveranstaltung ====

Wie auch die letzten Jahre gibt es eine Vorabendveranstaltung zur Konferenz:

    19:00 - 20:00 Uhr Empfang 
    Ab 20:00 Uhr Abendessen, Ende ca. 01:00 Uhr

sie findet im Restaurant Barfüßer (http://www.barfuesser-nuernberg.de/) statt:

    Hallplatz 2 
    90402 Nürnberg 
    Telefon 0911 20 42 42 

In gemütlicher Runde bietet sich die Möglichkeit, bestehende Kontakte zu vertiefen oder neue Kontakte zu knüpfen. Wir würden uns freuen, möglichst viele Teilnehmer auch hier begrüßen zu können. Über die Anmeldung zur Konferenz kann auch die Anmeldung zum Vorabendevent erfolgen.

 

==== it-sa / OWASP Messestand ====

[[Image:Itsa-2010-fair-plan.png|thumb|left]] Wie in den vergangenen beiden Jahren wird die OWASP an allen drei Messetagen wieder mit einem Stand auf der [http://www.it-sa.de/ it-sa] vertreten sein. Ihr findet uns am Stand 201, direkt beim Eingang West.

Neben Informationsmaterial und Give-Aways stehen Euch OWASP-Mitglieder Frage und Antwort zur OWASP und zum Thema Webanwendungssicherheit im Allgemeinen und Speziellen. Wir freuen uns auf spannende Gespräche und regen Zuspruch! Achja: Wer OWASP-Mitglied werden möchte, kann das natürlich gleich vor Ort machen ;)

==== Anreise ====

==== Infos für Sponsoren ====

Als Sponsor der OWASP AppSec Germany 2010 setzen Sie auch in diesem Jahr wieder ein klares Zeichen: Sie unterstützen den deutschen Branchentreffpunkt im Bereich Web Application Security trotz Finanzkrise und stärken so sichtbar das Image Ihres Unternehmens als Experte in diesem stark wachsenden Gebiet.

In diesem Jahr findet die OWASP AppSec Germany 2010 wie im letzten Jahr parallel zur Security-Messe it-sa in Nürnberg statt; dadurch ist u.a. eine sehr gute Einbindung der OWASP Konferenz in bestehende Marketing-Akivitäten, insbesondere seitens der Veranstalter der it-sa, gegeben. Im Rahmen einer Konferenz-begleitenden Ausstellung können Sie die Teilnehmer mit einem eigenen Stand von Ihren Produkten und/oder Dienstleistungen überzeugen. Aus Platzgründen sind maximal sechs Stände möglich. Diese werden nach dem Zeitpunkt des Eingangs der verbindlichen Zusage “first come first served” vergeben. Nach heutigem Kenntnisstand erwarten wir zwischen 100 – 150 Teilnehmer aus verschiedenen Branchen, insbesondere Finanz-, eBusiness- , Telekommunikationsindustrie. Sollten Sie nicht ausstellen wollen, so bieten wir Ihnen die Möglichkeit des einfachen “Logo- oder Roll-Up Sponsorings”

Alle Sponsoren-Einnahmen dienen ausschließlich der Kostendeckung der Konferenz sowie gegebenenfalls der Mission der unabhängigen und gemeinnützigen OWASP Foundation (501c3 Not-For-Profit).

Genaue Details zum Sponsoring finden Sie hier: http://www.owasp.org/images/7/74/OWASP_D_2010_SponsorenInfo.pdf

==== Call for Papers - German Version ====

Die deutsche Sektion des Open Web Application Security Project (OWASP) richtet die dritte Konferenz OWASP AppSec Germany 2010 am 20.10.2010 aus. Die Konferenz findet begleitend zur IT-Security-Messe it-sa in Nürnberg statt. Das German OWASP-Chapter ruft für diese Konferenz einen Call for Presentations (CfP) aus. Die Konferenz richtet sich primär an ein deutsches Publikum, die Konferenzsprache ist Deutsch, Vorträge sind aber auch in Englisch willkommen. Die OWASP AppSec Germany 2010 soll eine Ergänzung zu bekannten technologieorientierten Security-Konferenzen darstellen und Fachvorträge zu Entwicklung, Betrieb und Test von webbasierten Anwendungen bieten.

 

== Call for Presentations ==

Für die Einreichung von Vorträgen bitten wir um eine maximal zweiseitige Zusammenfassung oder eine Vorabversion des Vortrags.

Erwünscht sind alle Themen mit Bezug zu Web Application Security und OWASP, insbesondere:

*Praxisrelevante technische Vorträge
*Sichere Entwicklungs-Frameworks und Best Practices
*Secure Development Lifecycle
*Security-Awareness-Programme für Entwickler, Tester, Architekten und Auftraggeber
*Security-Management von Anwendungen im Unternehmen
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten
*Erfahrungsberichte aus Unternehmen, insbesondere bzgl. Einführung von Application-Security-Prozessen, internem und externem Auditing etc.
*OWASP in Ihrem Unternehmen, Ihrer Hochschule etc.
*Anwendungssicherheit und Metriken

Abhängig von der Anzahl eingehender Vorträge werden ein oder zwei Tracks angeboten. Präsentationen können 30 oder 45 Minuten dauern. Wird der Beitrag akzeptiert, kann ggfs. Rücksprache bzgl. der Länge erfolgen. Alle Vorträge werden unter der OWASP Lizenz (OWASP Speaker Agreement http://www.owasp.org/index.php/Speaker_Agreement) auf der Konferenzwebseite veröffentlicht. Das OWASP Speaker Agreement muss vor der Konferenz ohne Änderung akzeptiert und unterschrieben werden.

Voraussichtlich wird neben den Konferenzbeiträgen ein kleines Lab angeboten, in dem Demos aus den Vorträgen vorgeführt oder nach dem Vortrag einzelne Themen mit Interessierten praktisch vertieft werden können.

'''Teilnehmer und Vortragende sind herzlich eingeladen zur Vorabendveranstaltung am 19.10.2010.'''

 

== Program Committee ==

*Bruce Sams
*Martin Johns
*Kai Jendrian
*Boris Hemkemeier
*Dirk Wetter

 

== Termine ==

*Einreichungen bis '''15.08.2010''' Bitte fügen Sie eine Zusammenfassung des Vortrags (200-500 Worte), ggf. eine Vorabversion des Foliensatzes sowie eine Kurzbiographie (30-100 Worte) bei. Bitte geben Sie auch die gewünschte Dauer (30 oder 45 Minuten) mit an.
*Einreichungen online über http://www.easychair.org/conferences/?conf=appsecgermany2010 . Bitte geben sie alle vortragsrelevanten Informationen (siehe oben) in dem Feld "Abstract" ein. Weiterhin haben Sie die Möglichkeit, bis zu zwei Dateien (z.B. Papier, Folien oder Biographie) hochzuladen.
*Benachrichtigung der Vortragenden: 15.08.2009.
*Einreichung der Foliensätze (prefinal): 01.10.2009
*Konferenz: 20.10.2010, Vorabendveranstaltung am 19.10.2010

 

==== Call for Papers - English Version ====

The German section of the Open Web Application Security Project (OWASP) announces a for Presentations (CfP) for the third OWASP AppSec Germany conference on the 20th of October 2010 in Nuremberg. The conference will be held in parallel with the IT security exhibition. The conference is primarily oriented toward a german speaking audience, but also presentations in English are welcome. The OWASP AppSec Germany 2010 will extend the range of typical security conferences with contributions covering development, operation and test of web-based applications.

 

== Call for Presentations ==

To submit a proposal, please send either a summary of no more than two pages in length or a preliminary version of the presentation.

We are interested in all topics related to Web Application Security and OWASP, in particular:

*Technical presentations related to operations
*Frameworks and best practices for secure development
*Secure Development Lifecycle
*Security awareness programs for developers, testers, architects and project owners
*Security management for applications in the corporate environment
*Application security for Outsourcing and Offshoring projekts
*Field reports from corporations regarding the institution of Web Application Security processes, internal and external auditing etc.
*OWASP in your workplace, university, etc.
*Metrics for application security

Depending on the number of submissions, we will offer either one or two tracks. Presentations can be either 30 or 45 minutes in length. If a proposal is accepted, we may contact you regarding the length. All presentations will be published on the conference website under the OWSAP license (see below). We would like to remind you that all speakers must accept and sign the [http://www.owasp.org/index.php/Speaker_Agreement OWASP Speaker Agreement] without changes prior to the conference.

We anticipate that a small lab session will be offered, in which demonstrations from the conference can be shown or in which participants can get in-depth information from the speakers.

'''Participants and speakers are all warmly invited to attend the evening program on the 19th of October 2010. '''

 

== Program Committee ==

*Bruce Sams
*Martin Johns
*Kai Jendrian
*Boris Hemkemeier
*Dirk Wetter

 

== Dates ==

*'''Submissions no later than 15 August 2010''' online via [http://www.easychair.org/conferences/?conf=appsecgermany2010 Easychair]. Please attach either a preliminary version of the presentation or a summary (200 to 500 words), and if possible, a brief biography (20 to 50 words). Please also state the desired length (30 or 45 Minutes).
*Notification of acceptance by 15 August 2010.
*Prefinal submission of the slides by 01 October 2010
*Conference: October 20, 2010. Evening program on the 19th of October, 2010

==== Kontakt / Contact ====

Für das CfP ist bitte die Applikation 'easychair' zu nutzen. Anfragen, die über die Einreichung von Präsentationen hinausgehen, bitte an die folgende E-Mail Adresse:

[mailto:ulrike.petersen@owasp.org ulrike.petersen@owasp.org]

<headertabs />

File:OWASP-Germany-AppSec2010.pdf

2010-10-25T09:37:03Z

AlexanderMeisel: distributed Web Application Firewall (dWAF) and the Cloud

distributed Web Application Firewall (dWAF) and the Cloud

Injection Prevention Cheat Sheet

2010-04-12T08:55:01Z

AlexanderMeisel: /* OS calls */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

= Application Types =

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

== A1: New Application ==

A new web application in the design phase, or in early stage development.

== A2: Productive Open Source Application ==

An already productive application, which can be easily adapted. A Model-View-Controller (MVC) type application is just one example of having a easily accessible application architecture.

== A3: Productive Closed Source Application ==

A productive application which cannot or only with difficulty be modified.

= Forms of Injection =

There are several forms of injection targeting different technologies:

== Query languages ==

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. For more information see the [[SQL Injection Prevention Cheat Sheet]].

But also LDAP, SOAP, XPath and REST based queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

== Scripting languages ==

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

Every time a scripting language is used, the actual implementation of the 'higher' scripting language is done using a 'lower' language like C. If the scripting language has a flaw in the data handling code 'Null Byte Injection' attack vectors can be deployed to gain access to other areas in memory, which results in a successful attack.

== Operating System (OS) Commands ==

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

== Network Protocols ==

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-12T08:54:04Z

AlexanderMeisel: /* A2: Productive Open Source Application */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

= Application Types =

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

== A1: New Application ==

A new web application in the design phase, or in early stage development.

== A2: Productive Open Source Application ==

An already productive application, which can be easily adapted. A Model-View-Controller (MVC) type application is just one example of having a easily accessible application architecture.

== A3: Productive Closed Source Application ==

A productive application which cannot or only with difficulty be modified.

= Forms of Injection =

There are several forms of injection targeting different technologies:

== Query languages ==

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. For more information see the [[SQL Injection Prevention Cheat Sheet]].

But also LDAP, SOAP, XPath and REST based queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

== Scripting languages ==

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

Every time a scripting language is used, the actual implementation of the 'higher' scripting language is done using a 'lower' language like C. If the scripting language has a flaw in the data handling code 'Null Byte Injection' attack vectors can be deployed to gain access to other areas in memory, which results in a successful attack.

== OS calls ==

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

== Network Protocols ==

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-12T08:51:46Z

AlexanderMeisel: /* Query languages */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

= Application Types =

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

== A1: New Application ==

A new web application in the design phase, or in early stage development.

== A2: Productive Open Source Application ==

An already productive application (with MVC architecture), which can be easily adapted.

== A3: Productive Closed Source Application ==

A productive application which cannot or only with difficulty be modified.

= Forms of Injection =

There are several forms of injection targeting different technologies:

== Query languages ==

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. For more information see the [[SQL Injection Prevention Cheat Sheet]].

But also LDAP, SOAP, XPath and REST based queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

== Scripting languages ==

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

Every time a scripting language is used, the actual implementation of the 'higher' scripting language is done using a 'lower' language like C. If the scripting language has a flaw in the data handling code 'Null Byte Injection' attack vectors can be deployed to gain access to other areas in memory, which results in a successful attack.

== OS calls ==

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

== Network Protocols ==

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-12T08:45:40Z

AlexanderMeisel: /* Scripting languages */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

= Application Types =

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

== A1: New Application ==

A new web application in the design phase, or in early stage development.

== A2: Productive Open Source Application ==

An already productive application (with MVC architecture), which can be easily adapted.

== A3: Productive Closed Source Application ==

A productive application which cannot or only with difficulty be modified.

= Forms of Injection =

There are several forms of injection targeting different technologies:

== Query languages ==

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

== Scripting languages ==

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

Every time a scripting language is used, the actual implementation of the 'higher' scripting language is done using a 'lower' language like C. If the scripting language has a flaw in the data handling code 'Null Byte Injection' attack vectors can be deployed to gain access to other areas in memory, which results in a successful attack.

== OS calls ==

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

== Network Protocols ==

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Talk:Injection Prevention Cheat Sheet

2010-04-07T12:58:05Z

AlexanderMeisel: /* Missing, somehow in wiki as from 6-apr-10 */

====Following questions to the wiki as from 6-apr-10====
(items are the headlines in the wiki page):

* Introduction
: we read: "... especially SQL Injection, ..."
: Hmm, SQL Injection is #1 in OWASP top 10 2010 now, but XSS is famous and popular as SQL Injection.
: '''Q:''' why is XSS missing?

* A2:
:we read: "An already productive application (with MVC architecture) ..."
:'''Q:''' why is this restricted to MVC? I don't see any reason for that as OpenSource applications must not be MVC.

* OS calls
:I'd use the term ''OS Commanding''

* Rule #1 (Perform proper input validation):
: Input validation is just half the truth, in most cases output validation, better: proper output encoding, needs to be done. Input validation only applies to the program/script code itself, like ''eval()'' calls.
: A good description of the term and related terms can be found at: http://projects.webappsec.org/Improper-Input-Handling and http://projects.webappsec.org/Improper-Output-Handling
: '''Q:''' why is output validation missing? It's important for XSS, SQLI, LDAP, XPath etc..
: I agree that for this Cheat Sheet output validation is not important, but just using input validation may give (some people) a wrong sense of the problem. To be discussed.

==== Answers to questions and comments ====
* XSS is missing because the injection prevention cheat sheet is for the OWASP TOP 10 (new) especially for A1 .. XSS has its own major A2

* A2 ... comment taken ... MVC architecture is only mentioned as an example .. this statement needs to be clarified

* OS calls vs. OS commanding .... Jim what is your take on this as an native American English speaker? I personally don't like words with ing .. so OS commands might be better!?!?!?

* Output validation is related to the 'missing XSS topic' and that particular family of problems ... Output validation is mostly irrelevant for pure injection problems (excluding XSS - Top10 A2 and XSRF - Top10 A5)

====Missing, somehow in wiki as from 6-apr-10====

* Forms of Injection
: I'm missing XSS. According the other headlines in this section, it proably should be named ''Content Spoofing'' and/or ''Client-side Injection''.
: Also think about AJAX (JSON) injection also (the client-side impact).

* Application Protocol
:The application protocol, HTTP here, can also be injected. Think of %0d%0a injections in the URL. This may lead to all sorts of HRS (HTTP Response Splitting/Smuggling, HTTP Request Smuggling/Splitting). It may also lead to HTTP header injections for example setting cookies.

* File Include - RFI, LFI
:Most web application frameworks support file inclusion, wether they are additional script code or some data. Improper data validation may lead to include program code or data from unexpected sources. Most common are vulneranilities in PHP. But SSI and even Java may be vulnerable.

* Format String
: If unvalidated user data are used as input to formatting strings, for example in C/C++ functions like fprintf, printf, sprintf, ..., arbitrary code may be executed or software crashes.

* Null Byte Injection
: This injection can alter intended application logic and allow malicious code injected. It can also be used to bypass sanity checks or filters in web applications or WAFS by adding URL-encoded null byte characters: %00.

* URL Redirector Abuse
: Bug or feature? It's an injection vulnerability, somehow.
: Not sure if it should be added.

* Web Services
: Beside the already mentioned XPath and XML injection, there is SOAP, REST, Schema Injection and Routing Detour (probably some more, not sure about all the proper terms used here).

==== Answers to Missing information ====

* XSS ... comments above ....

* Application protocol ... is CSRF ... has it own OWASP Top 10 entry ... the rest is covered by network protocols

* File Inclusion .... should actually be covered by 'Scripting languages' ... the text needs to be more precise

* Format string manipulation ... good idea but haven't seen any attacks in the wild. Jim what is your take on this?

* Null Byte Injection ... should actually part of the Query and Scripting language section because it clearly a language flaw of all major languages

* URL Redirection abuse ... this is OWASP Top 10 A8 ...

* Web Services ... lets take SOAP, REST, Schema Injection (is there an example anywhere ... I have seen that the schema definition gets downloaded but not used) ... Routing Detour (a good example would be nice ... Armin do you have one)

Talk:Injection Prevention Cheat Sheet

2010-04-07T12:43:09Z

AlexanderMeisel: /* Answers to questions and comments */

Talk:Injection Prevention Cheat Sheet

2010-04-07T12:40:55Z

AlexanderMeisel: /* Following questions to the wiki as from 6-apr-10 */

====Following questions to the wiki as from 6-apr-10====
(items are the headlines in the wiki page):

* Introduction
: we read: "... especially SQL Injection, ..."
: Hmm, SQL Injection is #1 in OWASP top 10 2010 now, but XSS is famous and popular as SQL Injection.
: '''Q:''' why is XSS missing?

* A2:
:we read: "An already productive application (with MVC architecture) ..."
:'''Q:''' why is this restricted to MVC? I don't see any reason for that as OpenSource applications must not be MVC.

* OS calls
:I'd use the term ''OS Commanding''

* Rule #1 (Perform proper input validation):
: Input validation is just half the truth, in most cases output validation, better: proper output encoding, needs to be done. Input validation only applies to the program/script code itself, like ''eval()'' calls.
: A good description of the term and related terms can be found at: http://projects.webappsec.org/Improper-Input-Handling and http://projects.webappsec.org/Improper-Output-Handling
: '''Q:''' why is output validation missing? It's important for XSS, SQLI, LDAP, XPath etc..
: I agree that for this Cheat Sheet output validation is not important, but just using input validation may give (some people) a wrong sense of the problem. To be discussed.

==== Answers to questions and comments ====
* XSS is missing because the injection prevention cheat sheet is for the OWASP TOP 10 (new) specially for A1 .. XSS has its own major A2

* A2 ... comment taken ... MVC architecture is only mentioned as an example .. this statement needs to be clarified

* OS calls vs. OS commanding .... Jim what is your take on this as an native American English speaker? I personally don't like words with ing .. so OS commands might be better!?!?!?

* Output validation is related to the 'missing XSS topic' and that particular family of problems ... Output validation is mostly irrelevant for pure injection problems (excluding XSS - Top10 A2 and XSRF - Top10 A5)

====Missing, somehow in wiki as from 6-apr-10====

* Forms of Injection
: I'm missing XSS. According the other headlines in this section, it proably should be named ''Content Spoofing'' and/or ''Client-side Injection''.
: Also think about AJAX (JSON) injection also (the client-side impact).

* Application Protocol
:The application protocol, HTTP here, can also be injected. Think of %0d%0a injections in the URL. This may lead to all sorts of HRS (HTTP Response Splitting/Smuggling, HTTP Request Smuggling/Splitting). It may also lead to HTTP header injections for example setting cookies.

* File Include - RFI, LFI
:Most web application frameworks support file inclusion, wether they are additional script code or some data. Improper data validation may lead to include program code or data from unexpected sources. Most common are vulneranilities in PHP. But SSI and even Java may be vulnerable.

* Format String
: If unvalidated user data are used as input to formatting strings, for example in C/C++ functions like fprintf, printf, sprintf, ..., arbitrary code may be executed or software crashes.

* Null Byte Injection
: This injection can alter intended application logic and allow malicious code injected. It can also be used to bypass sanity checks or filters in web applications or WAFS by adding URL-encoded null byte characters: %00.

* URL Redirector Abuse
: Bug or feature? It's an injection vulnerability, somehow.
: Not sure if it should be added.

* Web Services
: Beside the already mentioned XPath and XML injection, there is SOAP, REST, Schema Injection and Routing Detour (probably some more, not sure about all the proper terms used here).

Injection Prevention Cheat Sheet

2010-04-06T14:21:20Z

AlexanderMeisel: /* Introduction */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

= Application Types =

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

== A1: New Application ==

A new web application in the design phase, or in early stage development.

== A2: Productive Open Source Application ==

An already productive application (with MVC architecture), which can be easily adapted.

== A3: Productive Closed Source Application ==

A productive application which cannot or only with difficulty be modified.

= Forms of Injection =

There are several forms of injection targeting different technologies:

== Query languages ==

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

== Scripting languages ==

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

== OS calls ==

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

== Network Protocols ==

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T14:18:30Z

AlexanderMeisel: /* Injection Prevention Matrix */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type.

In order to fix or prevent the problem there are currently three ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T14:16:07Z

AlexanderMeisel: /* Rule #2 (Use a safe API): */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type. In order to fix or prevent the problem there are currently ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T14:04:47Z

AlexanderMeisel: /* Injection Prevention Matrix */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type. In order to fix or prevent the problem there are currently ways of doing it:

* (Re-)Design:
With a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type A1'''</center>
| <center>'''App Type A2'''</center>
| <center>'''App Type A3'''</center>

|-
| (Re)Design
| easy
| hard
| n/a

|-
| Rewrite
| medium
| hard
| n/a

|-
| WAF
| medium
| medium
| medium
|}

Depending on the application and the proposed solution a specific amount work is required.

* easy: little work required
* medium: moderate amount of work required
* hard: considerable amount of work required
* n/a: not possible

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T14:00:14Z

AlexanderMeisel: /* Injection Prevention Matrix */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

The matrix below shows how much work is required depending on the proposed solution and the application type. In order to fix or prevent the problem there are currently ways of doing it:

* (Re-)Design:
Which a clear application design decision the injection problem can be avoided. Using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary.

* Internal Patching / Code Rewrite:
Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation

* External Patching / Web Application Firewall:
Deploy a web application firewall to introduce virtual patching capability (black, white and pro active security measures)

{| class="prettytable" style="border-width:1px"
| <center>'''Solution'''</center>
| <center>'''App Type 1'''</center>
| <center>'''App Type 2'''</center>
| <center>'''App Type 3'''</center>

|-
| (Re)Design
| 1
| 3
| -

|-
| Rewrite
| 2
| 3
| -

|-
| WAF
| 2
| 2
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work required
* 2 moderate amount of work required
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T13:44:53Z

AlexanderMeisel: /* Rule #0 (Perform proper input validation): */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #1 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

{| class="prettytable" style="border-width:1px"
| <center>'''App'''</center>
| <center>'''Solution'''</center>
| <center>'''est. Work'''</center>

|-
| A1
| Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary
| 1

|-
| A2
| Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation
| 3

|-
| A3
| Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures)
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work required
* 2 moderate amount of work required
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-06T13:44:39Z

AlexanderMeisel: /* Rule #1 (Use a safe API): */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #2 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

{| class="prettytable" style="border-width:1px"
| <center>'''App'''</center>
| <center>'''Solution'''</center>
| <center>'''est. Work'''</center>

|-
| A1
| Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary
| 1

|-
| A2
| Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation
| 3

|-
| A3
| Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures)
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work required
* 2 moderate amount of work required
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-05T11:04:56Z

AlexanderMeisel: /* Forms of Applications */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Application Types ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #1 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

{| class="prettytable" style="border-width:1px"
| <center>'''App'''</center>
| <center>'''Solution'''</center>
| <center>'''est. Work'''</center>

|-
| A1
| Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary
| 1

|-
| A2
| Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation
| 3

|-
| A3
| Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures)
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work required
* 2 moderate amount of work required
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-05T11:03:16Z

AlexanderMeisel: /* Injection Prevention Matrix */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Forms of Applications ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #1 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

{| class="prettytable" style="border-width:1px"
| <center>'''App'''</center>
| <center>'''Solution'''</center>
| <center>'''est. Work'''</center>

|-
| A1
| Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary
| 1

|-
| A2
| Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation
| 3

|-
| A3
| Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures)
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work required
* 2 moderate amount of work required
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-05T11:02:36Z

AlexanderMeisel: /* Injection Prevention Rules */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Forms of Applications ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input.

=== Rule #1 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

= Injection Prevention Matrix =

{| class="prettytable" style="border-width:1px"
| <center>'''App'''</center>
| <center>'''Solution'''</center>
| <center>'''est. Work'''</center>

|-
| A1
| Can be avoided by using an OR-Mapper (e.g. Hibernate) or consistent parametrization of all input data (e.g. stored procedures or ideally: prepared statements). Other injection flaws (e.g. with XML) can only be avoided with dedicated output coding, where necessary
| 1

|-
| A2
| Rewrite parts of the application, to fix the problem or embed a library like the OWASP ESAPI to introduce black and white list based input validation
| 3

|-
| A3
| Deploy a web application firewall to introduce virtual patching (black, white and pro active security measures)
| 2
|}

Depending on the application and the proposed solution a specific amount work is required.

* 1 little work require
* 2 moderate amount of work require
* 3 considerable amount of work required

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-05T10:30:12Z

AlexanderMeisel: /* Forms of Applications */

= Introduction =

This article is focused on providing clear, simple, actionable guidance for preventing the entire category of Injection flaws in your applications. Injection attacks, especially [[SQL Injection]], are unfortunately very common.

Application accessibility is a very important factor in protection and prevention of injection flaws. Only the minority of all applications within a company/enterprise are developed in house, where as most applications are from external sources. Open source applications give at least the opportunity to fix problems, but closed source applications need a different approach to injection flaws.

== Problem Description ==

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Depending on the accessibility different actions must be taken in order to fix them. It is always the best way to fix the problem in source code itself, or even redesign some parts of the applications. But if the source code is not available or it is simply uneconomical to fix legacy software only virtual patching makes sense.

== Forms of Applications ==

Three classes of applications can usually be seen within a company. Those 3 types are needed to identify the actions which need to take place in order to prevent/fix injection flaws.

=== A1: New Application ===

A new web application in the design phase, or in early stage development.

=== A2: Productive Open Source Application ===

An already productive application (with MVC architecture), which can be easily adapted.

=== A3: Productive Closed Source Application ===

A productive application which cannot or only with difficulty be modified.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass. For more information see the [[SQL Injection Prevention Cheat Sheet]].

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (Perform proper input validation): ===

Perform proper input validation. Positive or “whitelist” input validation with appropriate canonicalization is also recommended, but is not a complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines.

=== Rule #1 (Use a safe API): ===

The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.
If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI has some of these escaping routines.

=== Rule #3 (Contextually escape user data): ===

If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter.

[[Category:OWASP Application Security Verification Standard Project]]
[[Category:OWASP Enterprise Security API]]
[[Category:How To]]
[[Category:Cheatsheets]]

Injection Prevention Cheat Sheet

2010-04-05T10:19:42Z

AlexanderMeisel: /* Problem Description */

Injection Prevention Cheat Sheet

2010-04-05T10:00:53Z

AlexanderMeisel: /* Introduction */

Injection Cheat Sheet

2010-04-01T11:26:02Z

AlexanderMeisel: First Version

= Introduction =

== Problem Description ==

Injection vulnerabilities are a form of '''data becomes code''' issue. The transition from data to code often happens due to ''in-band'' control characters, which mark the beginning (and end) of a commando block. Injected data can be (if syntactically correct) interpreted by an interpreter performing various tasks on the given input. An "interpreter" here is anything that receives and executes commands. Injection attacks are usually server and web application centric attacks with perfectly valid application layer traffic and is thus hard to detect for classic network security components.

== Forms of Injection ==

There are several forms of injection targeting different technologies:

=== Query languages ===

The most famous form of injection is SQL Injection where an attacker can modify existing database queries. But also LDAP and XPath queries can be susceptible to injection attacks allowing for data retrieval or control bypass.

=== Scripting languages ===

All scripting languages used in web applications have a form of an eval call which receives code at runtime and executes it. If code is crafted using unvalidated user input code injection can occur which allows an attacker to subvert application logic and eventually to gain local access.

=== OS calls ===

Application developers sometimes implement operating system interactions using calls to system utilities to create and remove directories for example. Here unvalidated input can lead to arbitrary OS commands being executed.

=== Network Protocols ===

Web applications often communicate with network daemons (like SMTP, IMAP, FTP) where user input becomes part of the communication stream. Here it is possible to inject command sequences to abuse an established session.

= Injection Prevention Rules =

=== Rule #0 (''Golden Rule''): ===

• Perform proper input validation.

• Prefer whitelisting (allow known good values) over blacklisting (deny known bad values).

=== Rule #1 (Query Languages): ===

• Where available (SQL) use prepared statements and stored procedures ([http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet]).

• Do DB and query language specific escaping and encoding on user supplied input.

• Filter control characters ( ' ; -- /**/ ( ) etc.).

=== Rule #2 (Scripting Languages): ===

• Avoid the use of dynamically evaluated code with user input.

• If you can not: perform strict whitelisting of known good values.

• Avoid the use of dynamically evaluated code with user input.

=== Rule #3 (OS Calls): ===

• Do not use calls to system utilities. Every language provides interaction with the operating system. Use language specific packages.

=== Rule #4 (Network Protocols): ===

• If your application talks to network daemons filter protocol specific control characters (%0d, %0a etc.).

=== Additional Defense: ===

• Use a Web Application Firewall (WAF):

    ⁃ Helps you protect closed source applications and third party components.

    ⁃ Can do extended whitelisting and blacklisting until the code is fixed.

• Use the least privileged accounts for all tasks to mitigate the level of access if a component gets compromised. Do sandboxing (chroot) where possible.

OWASP German Chapter Stammtisch Initiative

2009-11-27T13:00:13Z

AlexanderMeisel: /* Bereits gehaltene Stammtisch-Vorträge */

==Was ist ein OWASP Stammtisch?==
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.

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

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.

==Stammtisch oder Chapter?==
Stammtische sind keine Konkurrenz für Chapter sondern eine willkommene Ergänzung. Sie ermöglichen regelmäßige Treffen im Rahmen der OWASP Comunity 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.

== Lokale Stammtische ==

==== München ====

===== Allgemeines =====

Der Münchner Stammtisch findet aktuell '''jeden dritten Mittwoch im Monat um 19:00 Uhr'''<s>im Restaurant / Biergarten '''"Löwe und Raute" in der Nymphenburger Str. 64 in 80335 München'''</s> statt. 

Für den Termin am '''* D I E N S T A G *, den 24.11.2009''' hat sich jedoch '''Ort und Zeit geändert!''' Details siehe unten. 

Es ist immer für 12 Personen reserviert, bei gutem Wetter (t > 18,0 °C, 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 dringend gebeten''', um ggf. weitere Ressourcen reservieren zu lassen.

===== Der 6. Münchner OWASP Stammtisch am 24.11.2009 (DIENSTAG!) =====

Es wird an diesem Termin einen '''Vortrag''' geben: [[File:Was eine WAF nicht kann-20091124.pdf|Was eine WAF (nicht) kann]]
 

Referent ist Mirko Dziadzka. 

'''Zeitplan:'''

*19:00 - 19:45 Vortrag
*19:45 - 20:15 Diskussion
*Ab 20:15 nach Belieben

Leider gab es in der ursprünglich vorgesehenen Gaststätte Probleme mit dem Beamer und der Leinwand. Um zu verhindern, dass nach dem Vortrag (der ebenfalls im Münchner Norden stattgefunden hätte) ein Umzug in die Gaststätte erfolgen muss, haben wir die Lokalität für November (und Oktober) komplett gewechselt. Der Vortragsteil und das gemütliche Beisammensein werden nun in der Gaststätte Fagana im Stadtteil Feldmoching stattfinden. 

Die geplanten Folgetermine:

*16.12.2009
*20.01.2010
*Aufgrund der anstehenden Umfragen zum Wochentag kann hier noch keine Aussage getroffen werden.

===== Um 19:00 im Gasthaus Fagana =====

Georg-Zech-Allee 15 80995 München Tel.: 089 - 31 47 663 

[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] 

'''Im Oktober also nicht im:''' <s>Gasthaus Löwe und Raute Nymphenburger Str. 64 80335 München Tel. 089 / 130 143 97 </s>

<s>[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] </s>

===== Geplante Stammtisch-Vorträge =====

Wir haben bereits einige interessante Themen aufgespürt, zu denen wir eventuell einen Vortragenden gewinnen können, der uns darüber mehr erzählt:

*ISO 27001
*ZK Framework

Sobald wir eine konkrete Zusage haben, werde ich das bei der Ankündigung des jeweiligen Termins mit bekannt geben. 

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

===== Bereits gehaltene Stammtisch-Vorträge =====

* November 2009: Was eine WAF (nicht) kann [https://mirko.dziadzka.de/Vortrag/owasp-waf-20091124.pdf (Folien)]
* Oktober 2009: Eine Kurzeinführung in Injection-Angriffe (Ralf Reinhardt)

===== Abstimmung über die zukünftigen Termine in 2010 =====

Es ist natürlich schwierig, alle terminlichen Wünsche unter einen Hut (egal, welche Farbe) zu bringen. Ich bitte jeden, der sich als guten Vorsatz für das neue Jahr genommen hat, den Münchner OWASP Stammtisch mindestens 3 Mal in 2010 zu besuchen, an die virtuelle Urne. Wer jetzt schon weiß, dass er das nicht will oder kann, den möchte ich bitten, *nicht* an der Abstimmung teil zu nehmen. Die Umfrage endet am 30.11.2009 und ist zweigeteilt: Wochentag (Mo. - Fr.) und Woche (1 - 4) im Monat: 

[http://www.doodle.com/9iiggp4zgqezpz7r - Umfrage über den künftigen Wochentag des Münchner OWASP-Stammtisches] 

[http://www.doodle.com/ypwcrc9is9swbeh3 - Umfrage über die künftige Wochen im Monat des Münchner OWASP-Stammtisches] 

===== Spread the word =====

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. 

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. 

Schönen Gruß, [mailto:ralf.reinhardt@owasp.org Ralf Reinhardt]

==== Frankfurt ====

===== Allgemeines =====

Ähnlich wie in München soll der Stammtisch hauptsächlich zum lockeren Austausch und Netzwerken dienen.

Eingeladen sind alle Interessierten an

*Application Security
*Web Application Security
*Secure Software Lifecycle
*Security-Awareness Programme für Entwickler, Tester, Architekten und Auftraggeber
*Security Management von Anwendungen im Unternehmen
*Anwendungssicherheit bei Outsourcing- und Offshoring-Projekten
*Anwendungssicherheit und Metriken
*und natürlich an OWASP selbst

===== Der 2. Frankfurter OWASP Stammtisch findet Mitte Januar statt (genauer Termin tbd) =====

Liebe Freunde von OWASP,

der 2. OWASP Stammtisch Frankfurt wird wieder in der [http://maps.google.de/places/de/frankfurt-am-main/kasseler-stra%C3%9Fe/1/-arche-nova Arche Nova, Kasseler Str. 1a, Frankfurt a.M.] stattfinden.

Ich bitte um eine kurze Anmeldung an [mailto:boris@owasp.org boris@owasp.org]. Wer kommen möchte, aber noch keinen aus der OWASP-Gemeinde kennt, fragt einfach an der Theke.

 Bis zum 12.11.2009 [mailto:boris@owasp.org Boris Hemkemeier]

==== Stuttgart ====

===== 1. Stuttgarter Stammtisch am 30.11. um 19 Uhr im Restaurant Columbus =====

Das Restarant Columbus (http://www.columbus-stuttgart.de/ - steht aber nicht viel drauf). ist direkt neben dem Universitätscampus Vaihingen, daher mit Auto und Bahn recht gut erreichbar.

Das erste Treffen dient dem Beschnuppern und gemeinsamen Pläne schmieden für die nächsten Male, also:

*Kennenlernen
*Standortwechsel?
*Interessenslage für Vorträge
*Sonstiges

===== Der Stammtisch wird dann ab Februar 2010 jeden ersten Montag im Monat stattfinden. =====

Wer also seine Jahresplanung gerade gestaltet: Kalender auf und gleich reinschreiben :)

Für die Planung wäre es spitze, wenn mir potentielle Interessenten bis 27.11. eine kurze Mail an
tglemser [at] tele-consulting.com schicken würden zwecks Reservierung.
Wer das verschwitzt darf aber auch kommen..

Wohlan, wir freuen uns auf Eure Teilnahme, sagt es Euren Kollegen und Freunden weiter.

Tobias

==== Düsseldorf ====

===== Coming soon! =====

Vorgeschlagen von: Sven Schlüter //TODO

==== Köln ====

===== Allgemeines =====

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.

 

===== 2. Kölner OWASP Stammtisch am 13.01.2010 =====

wir treffen uns zum zweiten Kölner Stammtisch am 13.01.2010 um 19Uhr.

Die Lokalität wird noch bekannt gegeben.

Bitte gebt mir noch eine [mailto:ralf.allar@gmx.de Rückmeldung], falls ihr kommt, damit ich einen Überblick über die Zahl der Anwesenden erhalte. Danke!

bis zum 13.01 [mailto:ralf.allar@gmx.de Ralf Allar]

==== Hamburg ====

===== Coming soon! =====

Vorgeschlagen von: Dr. Dirk Wetter //TODO <headertabs />

User:AlexanderMeisel

2009-11-13T16:28:35Z

AlexanderMeisel: First Version

'''Alexander Meisel (OWASP Germany)'''

A member of OWASP Germany, Alexander Meisel is CTO and founder of 'art of defence'. He is in charge of product development, professional services and support.

Speaker at OWASP NY 2008

Speaker at OWASP in Belgium 2008

Major contributor to OWASP’s whitepaper “Best Practices Guide: Web Application Firewalls,” which was released by the OWASP Germany Chapter has been translated into English, French, and Chinese.

Web Application Firewall

2009-02-26T12:41:13Z

AlexanderMeisel: /* Commercial Tools from OWASP Members Of This Type */

{{Template:Countermeasure}}

==Description==

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)]] and [[SQL Injection]]. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.

A far more detailed description is available at [http://en.wikipedia.org/wiki/Application_firewall Wikipedia]

==Strengths and Weaknesses==

==Important Selection Criteria==

* Very Few False Positives (i.e., should NEVER dissallow an authorized request)
* Strength of Default (Out of the Box) Defenses
* Power and Ease of Learn Mode
* Types of Vulnerabilities it can prevent
* Ability to keep individual users constrained to exactly what they have seen in the current session
* Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)
* Form Factor: Software vs. Hardware (Hardware generally preferred)

You may also use [https://www.owasp.org/index.php/Category:OWASP_Best_Practices:_Use_of_Web_Application_Firewalls Best Paractices: Use of Web Application Firewalls] to find out where and when to use a WAF and/or you may find
the [http://www.webappsec.org/projects/wafec/ Web Application Firewall Evaluation Criteria] useful for evaluating the performance and other characteristics of a WAF.

The [[London Chapter WAF event]] held in 2006 has some comparative info amongst the WAF Vendors that participated in the event.

==OWASP Tools Of This Type==

The [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project] is not a full blown WAF, but it is a strong Java/J2EE input validation filter that can be put in front of your application.

==Well Known Open Source Tools Of This Type==

* [http://www.aqtronix.com/?PageID=99 AQTronix - WebKnight]
* [http://www.modsecurity.org/ Breach - ModSecurity]

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.artofdefence.com/en/hyperguard/hyperguard.html art of defence - hyperguard]
* [http://www.breach.com Breach - WebDefend]
* [http://www.denyall.com/produits.html?set_lang=en Deny All - rWeb]
* [http://fortifysoftware.com/products/defender/ Fortify Software - Defender]
* [http://www.imperva.com/products/securesphere/web_application_firewall.html Imperva - SecureSphere™]

==Other Well Known Commercial Tools Of This Type==

* [http://www.applicure.com Applicure - DotDefender]
* [http://www.armorlogic.com/ Armorlogic - Profense]
* [http://www.barracudanetworks.com/ns/products/web-application-controller-overview.php Barracuda Networks - Application Firewall]
* [http://www.bee-ware.net/en/product/i-sentry/ Bee-Ware - iSentry]
* [http://binarysec.com/ BinarySec - Application Firewall]
* [http://www.bugsec.com/products.php?Security=3&Subject=WebSniper BugSec - WebSniper]
* [http://www.citrix.com/English/ps2/products/product.asp?contentID=25636 Citrix - Application Firewall]
* [http://www.eeye.com/html/products/secureiis/index.html eEye Digital Security - SecureIIS]
* [http://www.f5.com/products/big-ip/product-modules/application-security-manager.html F5 - Application Security Manager]
* [http://forumsys.com/ Forum Systems - Xwall, Sentry]
* [http://www.webscurity.com/products.htm mWEbscurity - webApp.secure]
* [http://www.phion.com/INT/products/websecurity/Pages/default.aspx Phion / Visonys - Airlock]
* [http://www.xtradyne.com/ Xtradyne - Application Firewalls]
* [http://www.protegrity.com/WebApplicationFirewall Protegrity - Defiance TMS - Web Application Firewall]

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:OWASP Tools Project]]
[[Category: Control]]

Web Application Firewall

2009-01-28T15:39:20Z

AlexanderMeisel: /* Commercial Tools from OWASP Members Of This Type */

{{Template:Countermeasure}}

==Description==

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)]] and [[SQL Injection]]. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.

A far more detailed description is available at [http://en.wikipedia.org/wiki/Application_firewall Wikipedia]

==Strengths and Weaknesses==

==Important Selection Criteria==

* Very Few False Positives (i.e., should NEVER dissallow an authorized request)
* Strength of Default (Out of the Box) Defenses
* Power and Ease of Learn Mode
* Types of Vulnerabilities it can prevent
* Ability to keep individual users constrained to exactly what they have seen in the current session
* Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)
* Form Factor: Software vs. Hardware (Hardware generally preferred)

You may also find the [http://www.webappsec.org/projects/wafec/ Web Application Firewall Evaluation Criteria] useful for evaluating the performance and other characteristics of a WAF.

The [[London Chapter WAF event]] held in 2006 has some comparative info amongst the WAF Vendors that participated in the event.

==OWASP Tools Of This Type==

The [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project] is not a full blown WAF, but it is a strong Java/J2EE input validation filter that can be put in front of your application.

==Well Known Open Source Tools Of This Type==

* [http://www.aqtronix.com/?PageID=99 AQTronix - WebKnight]
* [http://www.modsecurity.org/ Breach - ModSecurity]

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.artofdefence.com/en/hyperguard/hyperguard.html art of defence - hyperguard]
* [http://www.breach.com Breach - WebDefend]
* [http://www.denyall.com/produits.html?set_lang=en Deny All - rWeb]
* [http://fortifysoftware.com/products/defender/ Fortify Software - Defender]
* [http://www.imperva.com/products/securesphere/web_application_firewall.html Imperva - SecureSphere™]
* [http://www.microsoft.com/isaserver/default.mspx Microsoft - ISA]

==Other Well Known Commercial Tools Of This Type==

* [http://www.applicure.com Applicure - DotDefender]
* [http://www.armorlogic.com/ Armorlogic - Profense]
* [http://www.barracudanetworks.com/ns/products/web-application-controller-overview.php Barracuda Networks - Application Firewall]
* [http://www.bee-ware.net/en/product/i-sentry/ Bee-Ware - iSentry]
* [http://binarysec.com/ BinarySec - Application Firewall]
* [http://www.bugsec.com/products.php?Security=3&Subject=WebSniper BugSec - WebSniper]
* [http://www.citrix.com/English/ps2/products/product.asp?contentID=25636 Citrix - Application Firewall]
* [http://www.eeye.com/html/products/secureiis/index.html eEye Digital Security - SecureIIS]
* [http://www.f5.com/products/TrafficShield/ F5 - TrafficShield]
* [http://forumsys.com/ Forum Systems - Xwall, Sentry]
* [http://www.webscurity.com/products.htm mWEbscurity - webApp.secure]
* [http://www.visonys.com/Die_Loesung_visonysAirlock_211.en.html Visonys - Airlock]
* [http://www.xtradyne.com/ Xtradyne - Application Firewalls]

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:OWASP Tools Project]]
[[Category: Control]]

Web Application Firewall

2009-01-28T15:38:46Z

AlexanderMeisel: /* Other Well Known Commercial Tools Of This Type */

{{Template:Countermeasure}}

==Description==

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)]] and [[SQL Injection]]. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.

A far more detailed description is available at [http://en.wikipedia.org/wiki/Application_firewall Wikipedia]

==Strengths and Weaknesses==

==Important Selection Criteria==

* Very Few False Positives (i.e., should NEVER dissallow an authorized request)
* Strength of Default (Out of the Box) Defenses
* Power and Ease of Learn Mode
* Types of Vulnerabilities it can prevent
* Ability to keep individual users constrained to exactly what they have seen in the current session
* Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)
* Form Factor: Software vs. Hardware (Hardware generally preferred)

You may also find the [http://www.webappsec.org/projects/wafec/ Web Application Firewall Evaluation Criteria] useful for evaluating the performance and other characteristics of a WAF.

The [[London Chapter WAF event]] held in 2006 has some comparative info amongst the WAF Vendors that participated in the event.

==OWASP Tools Of This Type==

The [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project] is not a full blown WAF, but it is a strong Java/J2EE input validation filter that can be put in front of your application.

==Well Known Open Source Tools Of This Type==

* [http://www.aqtronix.com/?PageID=99 AQTronix - WebKnight]
* [http://www.modsecurity.org/ Breach - ModSecurity]

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.breach.com Breach - WebDefend]
* [http://www.denyall.com/produits.html?set_lang=en Deny All - rWeb]
* [http://fortifysoftware.com/products/defender/ Fortify Software - Defender]
* [http://www.imperva.com/products/securesphere/web_application_firewall.html Imperva - SecureSphere™]
* [http://www.microsoft.com/isaserver/default.mspx Microsoft - ISA]

==Other Well Known Commercial Tools Of This Type==

* [http://www.applicure.com Applicure - DotDefender]
* [http://www.armorlogic.com/ Armorlogic - Profense]
* [http://www.barracudanetworks.com/ns/products/web-application-controller-overview.php Barracuda Networks - Application Firewall]
* [http://www.bee-ware.net/en/product/i-sentry/ Bee-Ware - iSentry]
* [http://binarysec.com/ BinarySec - Application Firewall]
* [http://www.bugsec.com/products.php?Security=3&Subject=WebSniper BugSec - WebSniper]
* [http://www.citrix.com/English/ps2/products/product.asp?contentID=25636 Citrix - Application Firewall]
* [http://www.eeye.com/html/products/secureiis/index.html eEye Digital Security - SecureIIS]
* [http://www.f5.com/products/TrafficShield/ F5 - TrafficShield]
* [http://forumsys.com/ Forum Systems - Xwall, Sentry]
* [http://www.webscurity.com/products.htm mWEbscurity - webApp.secure]
* [http://www.visonys.com/Die_Loesung_visonysAirlock_211.en.html Visonys - Airlock]
* [http://www.xtradyne.com/ Xtradyne - Application Firewalls]

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:OWASP Tools Project]]
[[Category: Control]]

Source Code Analysis Tools

2009-01-28T15:38:08Z

AlexanderMeisel: /* Commercial Tools from OWASP Members Of This Type */

Source Code Analysis tools are designed to analyze source code and/or compiled version of code in order to help find security flaws. Ideally, such tools would automatically find security flaws with a high degree of confidence that what is found is indeed a flaw. However, this is beyond the state of the art for many types of application security flaws. Thus, such tools frequently serve as aids for an analyst to help them zero in on security relevant portions of code so they can find flaws more efficiently, rather than a tool that simply finds flaws automatically.

Some tools are starting to move into the IDE. For the types of problems that can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to employ such tools, as it provides immediate feedback to the developer on issues they might be introducing into the code during code development itself. This immediate feedback is very useful as compared to finding vulnerabilities much later in the development cycle.

==Strengths and Weaknesses of such tools==

=== Strengths ===
* Scales Well (Can be run on lots of software, and can be repeatedly (like in nightly builds))
* For things that such tools can automatically find with high confidence, such as buffer overflows, SQL Injection Flaws, etc. they are great.

=== Weaknesses ===
* Many types of security vulnerabilities are very difficult to find automatically, such as authentication problems, access control issues, insecure use of cryptography, etc. The current state of the art only allows such tools to automatically find a relatively small percentage of application security flaws. Tools of this type are getting better, however.
* High numbers of false positives.
* Frequently can't find configuration issues, since they are not represented in the code.
* Difficult to 'prove' that an identified security issue is an actual vulnerability.
* Many of these tools have difficulty analyzing code that can't be compiled. Analysts frequently can't compile code because they don't have the right libraries, all the compilation instructions, all the code, etc.

==Important Selection Criteria==

* Requirement: Must support your language, but not usually a key factor once it does.

* Types of Vulnerabilities it can detect (Out of the OWASP Top Ten?) (plus more?)
* Does it require a fully buildable set of source?
* Can it run against binaries instead of source?
* Can it be integrated into the developer's IDE?

==OWASP Tools Of This Type==

* [[OWASP_LAPSE_Project | OWASP LAPSE Project]]

==Open Source or Free Tools Of This Type==

* [http://findbugs.sourceforge.net/ FindBugs] - Find Bugs (including some security flaws) in Java Programs
* [http://msdn.microsoft.com/en-us/library/bb429476(VS.80).aspx FxCop] (Microsoft) - FxCop is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
* [http://pmd.sourceforge.net/ PMD] - PMD scans Java source code and looks for potential code problems (this is a code quality tool that does not focus on security issues)
* [http://msdn.microsoft.com/en-us/library/ms933794.aspx PreFast] (Microsoft) - PREfast is a static analysis tool that identifies defects in C/C++ programs
* [http://www.fortify.com/security-resources/rats.jsp RATS] (Fortify) - Scans C, C++, Perl, PHP and Python source code for security problems like buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions
* [http://www.securitycompass.com/inner_swaat.shtml SWAAT] - Simplistic Beta Tool - Languages: Java, JSP, ASP .Net, and PHP

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.armorize.com/corpweb/en/products/codesecure Static Source Code Analysis with CodeSecure™] (Armorize Technologies)
* [http://www.artofdefence.com/en/hypersource/hypersource.html Static Source Code Analysis with hypersource] (art of defence)
* [http://www.fortifysoftware.com/products/sca.jsp Source Code Analysis] (Fortify)
* [http://www.ouncelabs.com/ Ounce] (Ounce Labs)

==Other Well Known Commercial Tools Of This Type==

* [http://www.coverity.com/products/prevent.html Prevent] (Coverity)
* [http://www.klocwork.com/products/insight.asp Insight] (KlocWork)

==More Info==

* TODO: add comments from: http://lists.owasp.org/pipermail/owasp-dotnet/2006-August/000002.html
* [[Appendix_A:_Testing_Tools | Appendix A: Testing Tools]]
* [http://samate.nist.gov/index.php/Source_Code_Security_Analyzers NIST's list of Source Code Security Analysis Tools]

[[Category:OWASP .NET Project]]

[[Category:OWASP Tools Project]]

__NOTOC__

Web Application Firewall

2009-01-28T15:34:44Z

AlexanderMeisel: /* Other Well Known Commercial Tools Of This Type */

{{Template:Countermeasure}}

==Description==

A web application firewall (WAF) is an appliance, server plugin, or filter that applies a set of rules to an HTTP conversation. Generally, these rules cover common attacks such as [[Cross-site Scripting (XSS)]] and [[SQL Injection]]. By customizing the rules to your application, many attacks can be identified and blocked. The effort to perform this customization can be significant and needs to be maintained as the application is modified.

A far more detailed description is available at [http://en.wikipedia.org/wiki/Application_firewall Wikipedia]

==Strengths and Weaknesses==

==Important Selection Criteria==

* Very Few False Positives (i.e., should NEVER dissallow an authorized request)
* Strength of Default (Out of the Box) Defenses
* Power and Ease of Learn Mode
* Types of Vulnerabilities it can prevent
* Ability to keep individual users constrained to exactly what they have seen in the current session
* Ability to be configured to prevent ANY specific problem (i.e., Emergency Patches)
* Form Factor: Software vs. Hardware (Hardware generally preferred)

You may also find the [http://www.webappsec.org/projects/wafec/ Web Application Firewall Evaluation Criteria] useful for evaluating the performance and other characteristics of a WAF.

The [[London Chapter WAF event]] held in 2006 has some comparative info amongst the WAF Vendors that participated in the event.

==OWASP Tools Of This Type==

The [http://www.owasp.org/index.php/Category:OWASP_Stinger_Project OWASP Stinger Project] is not a full blown WAF, but it is a strong Java/J2EE input validation filter that can be put in front of your application.

==Well Known Open Source Tools Of This Type==

* [http://www.aqtronix.com/?PageID=99 AQTronix - WebKnight]
* [http://www.modsecurity.org/ Breach - ModSecurity]

==Commercial Tools from OWASP Members Of This Type==

These vendors have decided to support OWASP by becoming [[Membership|members]]. OWASP appreciates the support from these organizations, but cannot endorse any commercial products or services.

* [http://www.breach.com Breach - WebDefend]
* [http://www.denyall.com/produits.html?set_lang=en Deny All - rWeb]
* [http://fortifysoftware.com/products/defender/ Fortify Software - Defender]
* [http://www.imperva.com/products/securesphere/web_application_firewall.html Imperva - SecureSphere™]
* [http://www.microsoft.com/isaserver/default.mspx Microsoft - ISA]

==Other Well Known Commercial Tools Of This Type==

* [http://www.artofdefence.com art of defence - hyperguard]
* [http://www.applicure.com Applicure - DotDefender]
* [http://www.armorlogic.com/ Armorlogic - Profense]
* [http://www.barracudanetworks.com/ns/products/web-application-controller-overview.php Barracuda Networks - Application Firewall]
* [http://www.bee-ware.net/en/product/i-sentry/ Bee-Ware - iSentry]
* [http://binarysec.com/ BinarySec - Application Firewall]
* [http://www.bugsec.com/products.php?Security=3&Subject=WebSniper BugSec - WebSniper]
* [http://www.citrix.com/English/ps2/products/product.asp?contentID=25636 Citrix - Application Firewall]
* [http://www.eeye.com/html/products/secureiis/index.html eEye Digital Security - SecureIIS]
* [http://www.f5.com/products/TrafficShield/ F5 - TrafficShield]
* [http://forumsys.com/ Forum Systems - Xwall, Sentry]
* [http://www.webscurity.com/products.htm mWEbscurity - webApp.secure]
* [http://www.visonys.com/Die_Loesung_visonysAirlock_211.en.html Visonys - Airlock]
* [http://www.xtradyne.com/ Xtradyne - Application Firewalls]

==Related Threats==

==Related Attacks==

==Related Vulnerabilities==

==Related Countermeasures==

[[Category:OWASP Tools Project]]
[[Category: Control]]

OWASP NYC AppSec 2008 Conference

2008-07-25T12:18:06Z

AlexanderMeisel: /* 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th */

= 2008 OWASP USA, NYC =
Last Update: {{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}

<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/6/61/Banner2_irfan.jpg]</center>
 
<hr>
<center>[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Diamond Sponsor] 1/1 - [http://www.imperva.com http://www.owasp.org/images/d/de/Imperva_2color_RGB.jpg] 
 [https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Platinum Sponsor] 2/3 - [http://www.whitehatsec.com http://www.owasp.org/images/archive/4/4d/20080703021901%21Whitehat.gif] - [http://www.cenzic.com/ https://www.owasp.org/images/b/bf/CenzicLogo_RGB.gif] - [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif] </center> 
[http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Gold, Silver & Other Sponsors] - [http://www.isc2.org http://www.owasp.org/images/4/45/Isc2logo.gif] - [http://www.f5.com http://www.owasp.org/images/7/7e/50px-F5_50px.jpg] - [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif] - [http://www.foundstone.com/us/education-overview.asp http://www.owasp.org/images/2/26/Foundstone.jpg] - [http://www.proactiverisk.com https://www.owasp.org/images/9/97/Proactiverisk_logo.jpg] - [http://www.ouncelabs.com https://www.owasp.org/images/6/6e/OunceLabs_logo.jpg] - [http://www.fortify.com https://www.owasp.org/images/a/ac/Fortify.jpg] - [http://www.cigital.com/ https://www.owasp.org/images/b/be/Cigital_OWASP.GIF] - [http://www.acunetix.com https://www.owasp.org/images/e/eb/Acuneti.gif] - [http://www.accessitgroup.com https://www.owasp.org/images/6/6d/Accessit.JPG] - [http://www.arctecgroup.net http://www.owasp.org/images/b/bf/Arctec.jpg] - [http://www.airtightnetworks.net https://www.owasp.org/images/8/8b/Airtight.gif] -
[http://www.artofdefence.com https://www.owasp.org/images/d/dc/AOD_Logo.gif] -
[http://www.securityuniversity.net https://www.owasp.org/images/0/0d/Security_university.jpg] -
[http://www.breach.com https://www.owasp.org/images/9/9c/Breach_logo.gif] ~ [http://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf http://www.owasp.org/images/f/f8/Sponsorsm.gif]
 
<center>[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities] -- [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-PRESS Press Registration] -- [http://www.owasp.org/index.php/Member_Offers Other OWASP Member Offers] </center>
<hr>
With assistance from: [http://www.webappsec.org WASC], [http://www.nym-infragard.us NYM InfraGard], [http://aitglobal.com AITGlobal], [http://nyphp.org/index.php NYC PHP], [http://www.nycbug.org NYCBUG], [http://www.isacany.net NYC ISACA], [http://www.nymissa.org NYC ISSA] and [http://www.pace.edu Pace University] you're invited to (2) days of Seminars and Technology Pavilion from the world's best application security technology minds, (2) days of hardcore hands-on training, all held at [http://www.pace.edu/page.cfm?doc_id=16157 Pace University], located in downtown New York City at One Pace Plaza New York, NY 10038. Event Fees: $350 Members / $400 Non-Members / $200 for Students for [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#OWASP_NYC_AppSec_2008_Training_Courses_-_September_22nd_and_23rd.2C_2008 2 days of hands on training classes] are also available.
<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]
To Get more involved and discuss this upcoming event [http://owaspfoundation.ning.com click here for forums] or visit other OWASP [http://www.owasp.org/index.php/Member_Offers member offers]
</center>

== 2008 OWASP USA, NYC Conference Schedule – Sept 24th - Sept 25th ==
<center>[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/speakeragreement OWASP Speaker Agreement]</center>
{| style="width:80%" border="0" align="center"
! colspan="4" align="center" style="background:#4058A0; color:white" | Day 1 – Sept 24th, 2008
|-
| style="width:10%; background:#7B8ABD" | || style="width:30%; background:#BC857A" | Track 1:
| style="width:30%; background:#BCA57A" | Track 2:
| style="width:30%; background:#99FF99" | Track 3:
|-
| style="width:10%; background:#7B8ABD" | 07:30-10:00 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | '''Doors Open for Attendee/Speaker Registration & [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference#Technology_Pavilion_-_September_24th_and_25th Exhibit/Sponsor Area]'''

|-
| style="width:10%; background:#7B8ABD" | 09:00-09:45 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | OWASP Version 3.0 who we are, where we are.. where we are going
''[http://www.owasp.org/index.php/Contact OWASP Foundation]: Jeff Williams, Dinis Cruz, Dave Wichers, Tom Brennan, Sebastien Deleersnyder, Paulo Coimbra, Kate Hartmann, Alison Shrader & all local chapter leaders
''
|-
| style="width:10%; background:#7B8ABD" | 10:00-10:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/AppSecEU08_Trends_in_Web_Hacking_Incidents:_What%27s_hot_for_2008 Analysis of the Web Hacking Incidents Database (WHID)]
''[http://blog.shezaf.com Ofer Shezaf]''
| style="width:30%; background:#BCA57A" align="left" | [http://www.webappsecroadmap.com Web Application Security Road Map] 
''[http://joesecurity.blogspot.com Joe White]''
| style="width:30%; background:#99FF99" align="left" |[https://buildsecurityin.us-cert.gov/swa/acqwg.html DHS Software Assurance Initiatives]
''[http://www.linkedin.com/pub/0/ab/3b7 Stan Wisseman] & [http://www.linkedin.com/pub/1/439/923 Joe Jarzombek]''
|-
| style="width:10%; background:#7B8ABD" | 11:00-11:45 || style="width:30%; background:#BC857A" align="left" | Web Security Education using Open Source Tools
''Prof. Li-Chiou Chen & Chienitng Lin, [http://www.pace.edu/page.cfm?doc_id=16399 Pace Univ]''
| style="width:30%; background:#BCA57A" align="left" | Http Bot Research
''[http://www.shadowserver.org/wiki/pmwiki.php?n=Shadowserver.Mission Andre M. DiMino - ShadowServer Foundation]''
| style="width:30%; background:#99FF99" align="left" | MalSpam Research
'' [http://www.knujon.com/bios.html Garth Bruen]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-13:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Sign-Up
''LUNCH - Provided by event sponsors @ TechExpo''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:30 || style="width:30%; background:#BC857A" align="left" | Cross-Site Scripting Filter Evasion
''Alexios Fakos''
| style="width:30%; background:#BCA57A" align="left" | Framework-level Threat Analysis: Adding Science to the Art of Source-code review
''Nishchal Bhalla''
| style="width:30%; background:#99FF99" align="left" | Automated Web-based Malware Behavioral Analysis
''[http://www.linkedin.com/pub/3/359/b1a Tyler Hudak]''
|-
| style="width:10%; background:#7B8ABD" | 13:00-13:45 || style="width:30%; background:#BC857A" align="left" | Offensive Assessing Financial Applications
'' [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-daniel-cuthbert Daniel Cuthbert]''
| style="width:30%; background:#BCA57A" align="left" | WAF ModSecurity
''[http://www.thinkingstone.com/about/ivan-ristic.html Ivan Ristic]''
| style="width:30%; background:#99FF99" align="left" | How the City of New York Uses Layer8 and OWASP to Secure Web Applications
''[http://www.linkedin.com/in/davidstern2000 David Stern] & [http://www.linkedin.com/in/romangarber Roman Garber]''

|-
| style="width:10%; background:#7B8ABD" | 14:00-14:45 || style="width:30%; background:#BC857A" align="left" | Logic Attacks and Inefficiencies of Robotic Detection
''[http://ha.ckers.org/blog/about Robert "RSnake" Hansen], CEO SecTheory''
| style="width:30%; background:#BCA57A" align="left" | Reverse Engineering .NET
''[http://www.linkedin.com/in/adamboulton Adam Boulton]''
| style="width:30%; background:#99FF99" align="left" | JBroFuzz 0.1 - 1.1: Building a Java Fuzzer for the Web
''[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Yiannis_Pavlosoglou Yiannis Pavlosoglou]''
|-
| style="width:10%; background:#7B8ABD" | 15:00-15:45 || style="width:30%; background:#BC857A" align="left" |Industry Outlook Panel: ''[http://www.linkedin.com/in/markclancy Mark Clancy] EVP CitiGroup, [http://www.linkedin.com/pub/0/497/86a Jim Routh] CISO DTCC, [http://www.linkedin.com/pub/0/bb1/68a Sunil Seshadri] CISO NYSE-Euronet, [http://www.linkedin.com/pub/0/1ba/4a9 Warren Axelrod] SVP Bank of America, [http://www.linkedin.com/in/bernik Joe Bernik] SVP, RBS,[http://www.linkedin.com/pub/8/878/240 Jennifer Bayuk] Infosec Consultant & [http://www.linkedin.com/in/philvenables Philip Venables] CISO, Goldman Sachs
[http://www.linkedin.com/in/mahidontamsetti Mahi Dontamsetti] Moderator''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Wild_Wild_Web_on_Security_Planet Wild Wild Web on Security Planet]
''[http://www.expresscertifications.com/company/execmgt.aspx Mano Paul] CEO Express Certifications''
| style="width:30%; background:#99FF99" align="left" |[http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-GunterOllmann Multidisciplinary Bank Attacks]
''Gunter Ollmann''
|-
| style="width:10%; background:#7B8ABD" | 16:00-16:45 || style="width:30%; background:#BC857A" align="left" | OWASP Enterprise Security API [http://www.owasp.org/index.php/ESAPI (ESAPI) Project]
'' [http://www.aspectsecurity.com/management.htm Jeff Williams] & Jim Manico''
| style="width:30%; background:#BCA57A" align="left" | Shootout @ Blackbox Corral
''Larry Suto ''
| style="width:30%; background:#99FF99" align="left" | Case Studies: Exploiting application testing tool deficiencies via "out of band" injection
''[http://www.linkedin.com/pub/0/a91/aa2 Vijay Akasapu] & [http://www.linkedin.com/pub/9/279/381 Marshall Heilman]''
|-
| style="width:10%; background:#7B8ABD" | 17:00-17:45 || style="width:30%; background:#BC857A" align="left" | Threading the Needle:

Bypassing web application/service security controls using Encoding, Transcoding, Filter Evasion, and other Canonicalization Attacks
'' [http://www.linkedin.com/in/arianevans Arian Evans]''
| style="width:30%; background:#BCA57A" align="left" |Shhhh Don’t Tell Anybody
''[http://www.linkedin.com/in/ppetkov Petko D. Petkov]''
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Andres_Riancho W3AF Open Source App Scanner]
''Andres Riancho''
|-
| style="width:10%; background:#7B8ABD" | 18:00-18:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_Live_CD_Project OWASP Live CD]
'' [http://www.linkedin.com/in/packetfocus Joshua Perrymon]''
| style="width:30%; background:#BCA57A" align="left" | Coding Secure w/PHP
''[http://www.linkedin.com/in/zaunere Hans Zaunere]''
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/Payment_Card_Data_Security_and_the_new_Enterprise_Java Payment Card Data Security and the new Enterprise Java]
''[https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Dr._B._V._Kumar Dr. B. V. Kumar] & [https://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference-SPEAKER-Abhay_Bhargav Mr. Abhay Bhargav]''
|-
| style="width:10%; background:#7B8ABD" | 20:00-23:00 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | OWASP NYC AppSec 2008 VIP Party
''Location: TBD''
|-
! colspan="10" align="center" style="background:#4058A0; color:white" | Day 2 – Sept 25th, 2008
|-
| style="width:10%; background:#99FF99" | 08:00-10:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | BREAKFAST - Provided by event sponsors @ TechExpo

|-
| style="width:10%; background:#7B8ABD" | 08:00-08:45 || style="width:30%; background:#BC857A" align="left" | State of the Union
''[http://www.aeispeakers.com/speakerbio.php?SpeakerID=1192 Prof. Howard A. Schmidt, CISSP, CISM (Hon.)] Current (ISC)² Security Strategist and Former White House Cyber Security Advisor''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/AppSecEU08_Best_Practices_Guide_Web_Application_Firewalls Best Practices Guide: Web Application Firewalls]
''Alexander Meisel''
| style="width:30%; background:#99FF99" align="left" | The Good The Bad and The Ugly - Pen Testing VS. Source Code Analysis
''[http://www.linkedin.com/in/tommyryan Thomas Ryan]''

|-
| style="width:10%; background:#7B8ABD" | 09:00-09:45 || style="width:30%; background:#BC857A" align="left" | Good vs. Evil JavaScript
''[http://jeremiahgrossman.blogspot.com Jeremiah Grossman]''
| style="width:30%; background:#BCA57A" align="left" | OWASP V2 Testing Guide 4.2.3 Spidering and Googling in depth
''[http://www.linkedin.com/in/ChristianHeinrich Christian Heinrich]''
| style="width:30%; background:#99FF99" align="left" | OWASP Web Services Top Ten
''[http://1raindrop.typepad.com Gunnar Peterson]''
|-
| style="width:10%; background:#7B8ABD" | 10:00-10:45 || style="width:30%; background:#BC857A" align="left" | OWASP Update
''Dinis Cruz/Jeff Williams + Surprise Guest''
| style="width:30%; background:#BCA57A" align="left" | Help Wanted 7 Things You Need to Know APPSEC/INFOSEC Employment
''[http://www.linkedin.com/pub/0/29/685 Lee Kushner]''
| style="width:30%; background:#99FF99" align="left" | APPSEC Analyst w/ Forrester Research
''[http://www.forrester.com/rb/analyst/chenxi_wang Chenxi Wang]''
|-
| style="width:10%; background:#7B8ABD" | 11:00-11:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_CLASP_Project CLASP (Comprehensive, Lightweight Application Security Process)]
''Pravir Chandra''
| style="width:30%; background:#BCA57A" align="left" | Next Generation Cross Site Scripting Worms
''[http://i8jesus.com/?page_id=5 Arshan Dabirsiaghi]''
| style="width:30%; background:#99FF99" align="left" | Secure Software Impact
''[http://ouncelabs.com/company/team.asp Jack Danahy]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:45 || style="width:30%; background:#BC857A" align="left" | Security in Agile Development
''[http://www.owasp.org/index.php/User:Wichers Dave Wichers]''
| style="width:30%; background:#BCA57A" align="left" | Security of Software-as-a-Service (SaaS)
''[http://www.linkedin.com/pub/6/372/45a James Landis]''
| style="width:30%; background:#99FF99" align="left" | [http://reversebenchmarking.com/About.html Open Reverse Benchmarking Project]
''Marce Luck & [http://www.linkedin.com/pub/1/507/616 Tom Stracener]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-13:00 || colspan="3" style="width:80%; background:#F2F2F2" align="center" | [http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference/ctf Capture the Flag] Status
''LUNCH - Provided @ TechExpo''
|-
| style="width:10%; background:#7B8ABD" | 13:00-13:45 || style="width:30%; background:#BC857A" align="left" | Security Research Report
''[http://www.linkedin.com/pub/5/742/233 Dinis Cruz]''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_Pantera_Web_Assessment_Studio_Project Pantera Advances]
''[http://www.linkedin.com/pub/1/598/855 Simon Roses Femerling]''
| style="width:30%; background:#99FF99" align="left" | Lotus Notes Insecurity
''Jian Hui Wang''
|-
| style="width:10%; background:#7B8ABD" | 14:00-14:45 || style="width:30%; background:#BC857A" align="left" | Practical Advanced Threat Modeling
''John Steven''
| style="width:30%; background:#BCA57A" align="left" | [http://www.owasp.org/index.php/Category:OWASP_Orizon_Project Owasp Orizon]
''Paolo Perego''
| style="width:30%; background:#99FF99" align="left" | [http://www.owasp.org/index.php/Building_Usable_Security Building Usable Security]
[http://www.owasp.org/index.php/Zed_Abbadi Zed Abbadi]
|-
| style="width:10%; background:#7B8ABD" | 15:00-15:45 || style="width:30%; background:#BC857A" align="left" | [http://www.owasp.org/index.php/Input_validation:_the_Good%2C_the_Bad_and_the_Ugly Input validation: the Good, the Bad and the Ugly]
''Johan Peeters''
| style="width:30%; background:#BCA57A" align="left" | Off-shoring Application Development? Security is Still Your Problem
''Rohyt Belani''
| style="width:30%; background:#99FF99" align="left" | NIST SAMATE Static Analysis Tool Exposition (SATE)
''Vadim Okun''
|-
| style="width:10%; background:#7B8ABD" | 16:00-16:45 || style="width:30%; background:#BC857A" align="left" | Vulnerabilities in application interpreters and runtimes
''Erik Cabetas''
| style="width:30%; background:#BCA57A" align="left" | Flash Parameter Injection (FPI)
''Ayal Yogev & Adi Sharabani''
| style="width:30%; background:#99FF99" align="left" | Mastering PCI Section 6.6
''[http://www.linkedin.com/pub/1/228/6a5 Taylor McKinley] and [http://www.linkedin.com/in/jacobwest Jacob West]''
|-
| style="width:10%; background:#7B8ABD" | 17:00-17:45 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | '''Wizdom of Crowds / CTF Awards & Raffles'''
|-
| style="width:10%; background:#7B8ABD" | 18:30-19:30 || colspan="3" style="width:80%; background:#C2C2C2" align="center" | OWASP Foundation, Chapter Leader Meeting
|}

<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 http://www.owasp.org/images/7/7f/Register.gif]</center>

== Technology Pavilion - September 24th and 25th ==

Want to see the latest offerings from technology product and service firms, visit the Technology Pavilion. On September 24th and 25th. 2 full days of exhibits by service providers and manufacturers from around the world.

Do you want to preview the event space [http://www.flickr.com/photos/21550725@N04/sets/72157604662279903/detail Click Here]

<hr>

== [http://www.owasp.org/index.php/Category:OWASP_AppSec_Conference_Training OWASP NYC AppSec 2008 Training Courses - September 22nd and 23rd, 2008] ==
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T1. Defensive Programming - 2-Days - $1350
|-
| style="background:#F2F2F2" | This class will teach you how to program defensively. A must for developers, managers, testers and security professionals. Learn the latest techniques to build attack resistant code, protect from current and future vulnerabilities and how to secure an application from both implementation bugs and design flaws. The instructor Pravir Chandra is well known security expert, project lead for OWASP CLASP project and former co-founder & CTO of secure software [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Jason Rouse, Technical Manager, [http://www.cigital.com/training/series http://www.owasp.org/images/b/be/Cigital_OWASP.GIF]'''
|-
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T2. Secure Coding for Java EE - 2-Days - $1350
|-
| style="background:#F2F2F2" | This course is similar to Aspect's Building and Testing Secure Web Applications except it includes a significant amount of Java focused content, including:
# Java EE security overview,
# All coding examples and recommendations are specifically focused on Java and Java servers, and
# 3 additional hands on coding labs where the students find and then fix security vulnerabilities in a Java EE application developed for the class.

[[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]
'''
|-
! align="center" style="background:#4058A0; color:white" | T3. Web Services and XML Security - 2-Days - $1350
|-
| style="background:#F2F2F2" | The movement towards Web Services and Service Oriented architecture (SOA) paradigms requires new security paradigms to deal with new risks posed by these architectures. This session takes a pragmatic approach towards identifying Web Services security risks and selecting and applying countermeasures to the application, code, web servers, databases, application, and identity servers and related software. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: Gunnar Peterson''' [http://www.arctecgroup.net https://www.owasp.org/images/b/bf/Arctec.jpg]
|-
! align="center" style="background:#4058A0; color:white" | T4. Advanced Web Application Security Testing - 2-Days - $1350
|-
| style="background:#F2F2F2" | Course Overview While all developers need to know the basics of web application security testing, application security specialists will want to know all the advanced techniques for finding and diagnosing security problems in applications. Aspect’s Advanced Web Application Security Testing training is based on a decade of work verifying the security of critical applications. The course is taught by an experienced application security practitioner in an interactive manner. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''
|-
! align="center" style="background:#4058A0; color:white" | T5. Leading the Development of Secure Applications 1-Day - Sept 22nd- $675
|-
| style="background:#F2F2F2" | In this one-day management session you’ll get the answers to the ten key questions that most CIOs and development managers face when trying to improve security in the development process. The course provides proven techniques and valuable lessons learned that can be applied to projects at any phase of their application’s lifecycle. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]
Instructor: This tutorial is provided by longtime OWASP contributor: [http://www.aspectsecurity.com http://www.owasp.org/images/d/d1/Aspect_logo.gif]'''
|-
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T8. Writing Secure Code ASP.NET - 2-Days - $1350
|-
| style="background:#F2F2F2" | Understand the key security features of the .NET platform, the common web security pitfalls developers make, and how to build secure and reliable web applications using ASP.NET. Students are lead through hands on code examples that highlight issues and prescribe solutions. [[:Category:OWASP_AppSec_Conference_Training | Learn More Here]]

The instructors are Foundstone's Technical Director, Rudolph Araujo and Foundstone's Professional Services Conlultant, Alex Smolen. [http://www.foundstone.com/us/education-overview.asp https://www.owasp.org/images/2/26/Foundstone.jpg]
|}
<center>[http://guest.cvent.com/i.aspx?4W,M3,828ca6d1-1b60-4105-8034-d344700e6956 https://www.owasp.org/images/7/7f/Register.gif]</center>

<h2> HOTELS / TRAVEL </h2>
[http://maps.google.com/maps?near=Pace+Plz,+New+York,+NY+10038+(Pace+University+New+York+Cmps)&geocode=15467452012610799558,40.711640,-74.005820&q=hotel&f=l&dq=Pace+University-New+York&ie=UTF8&z=15&om=0 Hotels in the area of the event]

New York City MTA: http://www.mta.nyc.ny.us/nyct/index.html

New York City Subway & walking directions: http://www.hopstop.com/?city=newyork

New York Sights & Sounds - SightsSounds

New York City Travel Guide - http://www.nytoday.com/

New York City Attractions - http://www.nycvisit.com

New York TV Show Tickets - Get free tickets to TV shows! - http://www.nytix.com/

New York City local news: http://www.ny1news.com

<h2>EVENT SPONSORSHIP </h2>The OWASP Conferences & Training security technologists including CSOs,admins, application admins, MIS directors, homeland defense chiefs. These important influencers drive buying decisions exclusive access to its audiences. OWASP has established strategic relationships with security—print publications, newsletters, portals, consultants,message—and leadership positioning OWASP events. OWASP’s mission is supported by organizations who share our application, and software security communities. This approach should be part of your mix.

[https://www.owasp.org/images/6/66/NY_Sponsorship_Form_update_%282%29.pdf Sponsorship Opportunities]- Register online: [http://guest.cvent.com/i.aspx?4W,M3,09e3b490-ba93-4474-851e-be803b1a01c2 click here]

OWASP AppSec Europe 2008 - Belgium

2008-05-21T13:34:06Z

AlexanderMeisel: /* Agenda and Presentations - May 21-22 */

[[Image:Owasp_banner_EU08.jpg]]

Welcome to the European OWASP Application Security Conference! After successful OWASP Conferences in the United States and Europe, we are back in Belgium: 5 tutorials and 2 conference tracks in the historic center of Ghent on May 19-22 2008!

The conference is stuffed with top notch presentations from industry recognised speakers and technical experts on the latest application security risks and trends. New for AppSec Europe: technical vendor demos and a Capture the Flag!

==Conference Location==
[[Image:GhentEU2008.JPG]]

The historic center of [http://en.wikipedia.org/wiki/Ghent Ghent], Belgium May 19th-22nd.

[[OWASP_AppSec_Europe_2008_-_Belgium/Training | Tutorial Days: May 19th-20th]]

[[OWASP_AppSec_Europe_2008_-_Belgium/Agenda | Main Conference: May 21st-22nd]]

'''Registration is available via the OWASP Conference Cvent site at: [http://guest.cvent.com/i.aspx?4W,M3,7b36ecdc-1234-4d63-bc08-898a7bf60b2a Cvent link]'''

'''If you are registering as a Speaker or Sponsor, please use the following link: [http://guest.cvent.com/i.aspx?4W,M3,49b0aaab-82ef-4a36-a982-6e56a485c531 Cvent link for speakers/sponsors]'''

You may want to print out [http://local.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=106138833491653132955.00044c6dc6d591427c620&ll=51.059388,3.729258&spn=0.019879,0.040169&z=15|usefull this map] of OWASP AppSec EU 2008 locations in Ghent.

==Agenda and Presentations - May 21-22==

The agenda follows the successful OWASP conference two tracks format, with opening keynotes and presentations in the main auditorium, split tracks in the middle of the day, and closing pannel discussions back in the main auditorium both days. As in the previous editions, the OWASP AppSec Europe 2008 conference will feature a refereed papers track.

{| style="width:80%" border="0" align="center"
! colspan="3" align="center" style="background:#4058A0; color:white" | Day 1 - May 21, 2008
|-
| style="width:10%; background:#7B8ABD" | || style="width:40%; background:#BC857A" | Track 1: Auditorium
| style="width:40%; background:#BCA57A" | Track 2: Council Room
|-
| style="width:10%; background:#7B8ABD" | 08:00-09:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Registration and Coffee
|-
| style="width:10%; background:#7B8ABD" | 09:00-09:05 || colspan="2" style="width:80%; background:#F2F2F2" align="center" | Welcome to OWASP AppSec 2008 Conference
''Sebastien Deleersnyder''
|-
| style="width:10%; background:#7B8ABD" | 09:05-09:45 || colspan="2" style="width:80%; background:#F2F2F2" align="center" | Keynote: The Great Information Security Scrap Yard Challenge
''Mark Curphey, Microsoft''
|-
| style="width:10%; background:#7B8ABD" | 09:45-10:20 || colspan="2" style="width:80%; background:#F2F2F2" align="center" | Owasp State of the Union
''Dinis Cruz''
|-
| style="width:10%; background:#7B8ABD" | 10:20-10:40 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Break - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 10:40-11:20 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_The_OWASP_ESAPI_project | Fundamental Application Security Building Blocks - The Benefits of Establishing an Enterprise Security API (ESAPI) for Your Organization]]
''[[User:Wichers | Dave Wichers]], Aspect Security''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_Trends_in_Web_Hacking_Incidents:_What's_hot_for_2008 | Trends in Web Hacking: What's hot in 2008 Analysis of the Web Hacking Incidents Database (WHID)]] ([[Media:AppSecEU2008-WHID.ppt‎|ppt]])
''[http://blog.shezaf.com Ofer Shezaf], Breach''
|-
| style="width:10%; background:#7B8ABD" | 11:20-12:00 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_Evaluation_Criteria_for_Web_Application_Firewalls | Evaluation Criteria for Web Application Firewalls]] ([https://www.owasp.org/images/f/f4/AppSecEU08_Evaluation_Criteria_for_Web_Application_Firewalls.pdf pdf])
''[http://blog.ivanristic.com Ivan Ristic], Breach''
| style="width:40%; background:#BCA57A" align="left" | HTML5 security
''Thomas Roessler''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:30 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_The_OWASP_ORIZON_project | The OWASP Orizon Project internals]]
''Paolo Perego''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_Remo_presentation |Remo presentation]] (Positive ModSecurity rulesets / Input validation)
''Christian Folini''
|-
| style="width:10%; background:#7B8ABD" | 12:30-14:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Lunch - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 14:00-14:40 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_Best_Practices_Guide_Web_Application_Firewalls | Best Practices Guide: Web Application Firewalls]] ([https://www.owasp.org/images/a/a4/AppSecEU08-BPWAF.pdf pdf])
''Alexander Meisel, art of defence''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_Input_validation:_the_Good,_the_Bad_and_the_Ugly|
Input validation: the Good, the Bad and the Ugly]] ([https://www.owasp.org/images/4/4c/AppSecEU08-JohanPeeters.pdf pdf])
[[Johan_Peeters|''Johan Peeters'']]
|-
| style="width:10%; background:#7B8ABD" | 14:40-15:20 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_NTLM_Relay_Attacks | NTLM Relay Attacks]] ([https://www.owasp.org/images/2/20/AppSecEU08_NTLM_Relay_Attacks-pptx.ppt ppt])
''Eric Rachner''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_PHPIDS_Monitoring_attack_surface_activity|PHPIDS Monitoring attack surface activity]] ([https://www.owasp.org/images/d/dd/AppSec08_PHPIDS_Monitoring_attack_surface_activity.ppt ppt])
''[http://mario.heideri.ch/ Mario Heiderich]''
|-
| style="width:10%; background:#7B8ABD" | 15:20-15:50 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_Agile_Security_Breaking_the_Waterfall_Mindset | Agile Security - Breaking the Waterfall Mindset of the Security Industry]]
''[[User:Wichers | Dave Wichers]], Aspect Security''
| style="width:40%; background:#BCA57A" align="left" | Security framework is not in the code ([https://www.owasp.org/images/a/ae/AppSecEU08-Sec_Frm_not_in_code.pdf pdf])
''Sam Reghenzi''
|-
| style="width:10%; background:#7B8ABD" | 15:50-16:10 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Break - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 16:10-17:00 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_Exploiting_Online_Games | Exploiting Online Games]]
''[[User:gem | Gary McGraw]], Cigital''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08 SHIELDS: metrics, tools and Internet services to improve security in application developments | SHIELDS: metrics, tools and Internet services to improve security in application developments]]
''[[AppSecEU08 Domenico Rotondi | Domenico Rotondi]], TXT e-solutions Spa''
|-
| style="width:10%; background:#7B8ABD" | 17:00-18:00 || colspan="2" style="width:40%; background:#F2F2F2" align="left" | Panel: The PCI 6.6 dogfight - to Scan or to WAF, this is the question
Moderator: [[User:Oshezaf|Ofer Shezaf]]
Panelists: Gary McGraw (Cigital), Ivan Ristic (Breach Security), Ory Segal (IBM), Mario Heiderich (PHPIDS)
|-
| style="width:10%; background:#7B8ABD" | 18:00-19:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | [[AppSecEU08 Leader Meeting | OWASP Leader Meeting ]] Organized by ''[[User:Mmeucci | Matteo Meucci]], Minded Security''
|-
| style="width:10%; background:#7B8ABD" | 19:00-21:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | OWASP Social Gathering: Dinner and Drinks at the Monasterium
|-
! colspan="3" align="center" style="background:#4058A0; color:white" | Day 2 - May 22, 2008
|-
| style="width:10%; background:#7B8ABD" | || style="width:40%; background:#BC857A" | Track 1: Auditorium
| style="width:40%; background:#BCA57A" | Track 2: Council Room
|-
| style="width:10%; background:#7B8ABD" | 08:00-09:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Coffee
|-
| style="width:10%; background:#7B8ABD" | 09:00-9:40 || colspan="2" style="width:80%; background:#F2F2F2" align="center" | Keynote: [[AppSecEU08 Software Security State of the Practice 2008 | Software Security: State of the Practice 2008]]
''[[user:gem | Gary McGraw]], Cigital''
|-
| style="width:10%; background:#7B8ABD" | 9:40-10:20 || colspan="2" style="width:80%; background:#F2F2F2" align="center" | Tour of OWASP projects
''Dinis Cruz (Chief OWASP Evangelist), [[User:Wichers | Dave Wichers]] (OWASP Board), Michael Eddington (OWASP Encoding Project, .NET Web Service Validation Project) ([https://www.owasp.org/images/f/f8/AppSecEU08-ReformAndCanoodle-Eddington.ppt ppt]) and Mark Roxberry (OWASP .NET Project)''
|-
| style="width:10%; background:#7B8ABD" | 10:20-10:40 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Break - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 10:40-11:20 || style="width:40%; background:#BC857A" align="left" | Graph Analysis for WebApps: From Nodes to Edges
''Simon Roses Femerling, Microsoft''
| style="width:40%; background:#BCA57A" align="left" | The OWASP Education Project
''[[User:Konbloma | Martin Knobloch]], Sogeti Nederland B.V.''
|-
| style="width:10%; background:#7B8ABD" | 11:20-12:00 || style="width:40%; background:#BC857A" align="left" | [[ AppSecEU08_The_Dynamic_Taint_Propagation_Finding_Vulnerabilities_Without_Attacking | Dynamic Taint Propagation: Finding Vulnerabilities Without Attacking]] ([https://www.owasp.org/images/d/d3/AppSecEU08_Dynamic_Taint_Propagation_OWASP.ppt ppt])
''[[User:mmadou | Matias Madou]], Fortify''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_Threat_Modeling_for_Application_Designers_and_Architects | Threat Modeling for Application Designers & Architects]] ([https://www.owasp.org/images/3/38/AppSecEU08_Threat_Modeling_AppSecEU08_v_9_2.ppt ppt])
''[[AppSecEU08 Shay Zalalichin Shay Zalalichin | Shay Zalalichin]]''
|-
| style="width:10%; background:#7B8ABD" | 12:00-12:30 || style="width:40%; background:#BC857A" align="left" |
[[AppSecEU08_Scanstud_-_Evaluating_static_analysis_tools | Scanstud: Evaluating static analysis tools]]

''[http://www.informatik.uni-hamburg.de/SVS/personnel/martin/index.php Martin Johns]'', ''Moritz Jodeit'', ''Wolfgang Koeppl'', ''Martin Wimmer''
| style="width:40%; background:#BCA57A" align="left" | [[AppSecEU08_Office_2.0:_Software_as_a_Service%2C_Security_on_the_Sidelines | Office 2.0: Software as a Service, Security on the Sidelines?]]
''[[User:JohnH | John Heasman]], NGSSoftware''
|-
| style="width:10%; background:#7B8ABD" | 12:30-14:00 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Lunch - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 14:00-14:40 || style="width:40%; background:#BC857A" align="left" | [[AppSecEU08 How Data Privacy affects Applications and Databases | How Data Privacy affects Applications and Databases]] ([https://www.owasp.org/images/6/61/AppSecEU08-DeMaeyerDirk.pdf pdf])
''[[AppSecEU08 Dirk De Maeyer | Dirk De Maeyer]]''
| rowspan="2" style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
'''Invited talk:'''

''Prof. Dieter Gollmann:'' Know Thyself!
|-
| style="width:10%; background:#7B8ABD" | 14:40-14:50 || rowspan="3" style="width:40%; background:#BC857A" align="left" | [[AppSecEU08_The_OWASP_Anti-Samy_project | The OWASP Anti-Samy project]] ([https://www.owasp.org/images/4/47/AppSecEU08-AntiSamy.ppt ppt])
''Jason Li, Aspect Security''
|-
| style="width:10%; background:#7B8ABD" | 14:50-15:10
| style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
''fukami and Ben Fuhrmannek:'' [http://www.owasp.org/images/1/10/OWASP-AppSecEU08-Fukami.pdf SWF and the Malware Tragedy]
|-
| style="width:10%; background:#7B8ABD" | 15:10-15:20
| rowspan="2" style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
''Andrew Petukhov and Dmitry Kozlov:'' [http://www.owasp.org/images/3/3e/OWASP-AppSecEU08-Petukhov.pdf Detecting Security Vulnerabilities in Web Applications Using Dynamic Analysis with Penetration Testing]
|-
| style="width:10%; background:#7B8ABD" | 15:20-15:30 || rowspan="2" style="width:40%; background:#BC857A" align="left" | Google-Hacking and Google-Shielding ([https://www.owasp.org/images/6/6a/AppSecEU08-BeyondGoogleHacking-AmichaiShulman.ppt ppt])
''Amichai Shulman''
|-
| style="width:10%; background:#7B8ABD" | 15:30-15:50
| style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
''Matias Madou, Edward Lee, Jacob West and Brian Chess:'' [http://www.owasp.org/images/9/9d/OWASP-AppSecEU08-Madou.pdf Watch What You Write: Preventing Cross-Site Scripting by Observing Program Output]
|-
| style="width:10%; background:#7B8ABD" | 15:50-16:10 || colspan="2" style="width:80%; background:#C2C2C2" align="left" | Break - Expo - CTF
|-
| style="width:10%; background:#7B8ABD" | 16:10-16:30 || rowspan="3" style="width:40%; background:#BC857A" align="left" | Client-side security
''pdp''
| style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
''Arshan Dabirsiaghi:'' [http://www.owasp.org/images/1/1b/OWASP-AppSecEU08-Dabirsiaghi.pdf Building and Stopping Next Generation XSS Worms]
|-
| style="width:10%; background:#7B8ABD" | 16:30-16:50
| style="width:40%; background:#BCA57A" align="left" | [http://www.cs.kuleuven.be/~lieven/AppSec2008/program.html Refereed papers track]
''Etienne Janot and Pavol Zavarsky:'' [http://www.owasp.org/images/5/57/OWASP-AppSecEU08-Janot.pdf Preventing SQL Injections in Online Applications: Study, Recommendations and Java Solution Prototype Based on the SQL DOM]
|-
| style="width:10%; background:#7B8ABD" | 16:50-17:00
| style="width:40%; background:#BCA57A" align="left" |
|-
| style="width:10%; background:#7B8ABD" | 17:00-18:00 || colspan="2" style="width:40%; background:#F2F2F2" align="left" | Panel: How to “sell” web application security to your organisation?
Moderator: tbd
Panelists: tbd
|-
| style="width:10%; background:#7B8ABD" | 18:00-18:10 || colspan="2" style="width:40%; background:#F2F2F2" align="left" | Conference Wrap Up - Dave Wichers, OWASP Conferences Chair
|-
|}

Venue: Aula, Ghent University, Voldersstraat 9, 9000 Ghent [http://maps.google.com/maps?f=q&hl=en&geocode=&q=Voldersstraat+9,+9000+Gent&jsv=107&sll=50.994753,3.745665&sspn=0.154284,0.466919&ie=UTF8&ll=51.054749,3.723121&spn=0.00963,0.029182&z=15&iwloc=addr Google Maps Link]

Registration is available via the OWASP Conference Cvent site at: [http://guest.cvent.com/i.aspx?4W,M3,7b36ecdc-1234-4d63-bc08-898a7bf60b2a Cvent link]

==Tutorial Days - May 19-20==

OWASP arranged for several Application Security tutorials on May 19th-20th, the days prior to the conference.
{| style="width:80%" border="0" align="center"
! align="center" style="background:#4058A0; color:white" | T1. Building and Testing Secure Web Applications
|-
| style="background:#F2F2F2" | Most developers, IT professionals, and auditors learn what they know about application security on the job, usually by making mistakes. Application security is just not a part of many computer science curricula today and most organizations have not focused on instituting a culture that includes application security as a core part of their IT security efforts. This powerful two day course focuses on the most common web application security problems, including the OWASP Top Ten. The course will introduce and demonstrate hacking techniques, illustrating how application vulnerabilities can be exploited so students really understand how to avoid introducing such vulnerabilities into their code.

Trainer: Jason Li, [http://www.aspectsecurity.com Aspect Security] - [[OWASP_AppSec_Europe_2008_-_Belgium/Training#T1._Building_and_Testing_Secure_Web_Applications_-_2-Day Course_-_May_19-20,_2008 | Read more here!]]
|-
! align="center" style="background:#4058A0; color:white" | T2. Leading the Development of Secure Applications
|-
| style="background:#F2F2F2" | In this one-day management session you’ll get the answers to the ten key questions that most CIOs and development managers face when trying to improve security in the development process. The course provides proven techniques and valuable lessons learned that can be applied to projects at any phase of their application’s lifecycle.

Trainer: Arshan Dabirsiaghi, [http://www.aspectsecurity.com Aspect Security] - [[OWASP_AppSec_Europe_2008_-_Belgium/Training#T2._Leading_the_Development_of_Secure_Applications_-_1-Day_Course_-_May_19,_2008 | Read more here!]]
|-
! align="center" style="background:#4058A0; color:white" | T3. Building Secure Rich Internet Applications
|-
| style="background:#F2F2F2" | Rich Internet applications using technologies like Ajax, Flash, ActiveX, and Java Applets require special attention to secure. This one day training addresses the special issues that arise in this type of application development.

Trainer: Arshan Dabirsiaghi, [http://www.aspectsecurity.com Aspect Security] - [[OWASP_AppSec_Europe_2008_-_Belgium/Training#T3._Building_Secure_Rich_Internet_Applications_-_1-Day_Course_-_May_20,_2008 | Read more here!]]
|-
! align="center" style="background:#4058A0; color:white" | T4. Building Secure Web Services
|-
| style="background:#F2F2F2" | The movement towards Web Services and Service Oriented architecture (SOA) paradigms requires new security paradigms to deal with new risks posed by these architectures. This session takes a pragmatic approach towards identifying Web Services security risks and selecting and applying countermeasures to the application, code, web servers, databases, application, and identity servers and related software. Many enterprises are currently developing new Web Services and/or adding and acquiring Web Services functionality into existing applications -- now is the time to build security into the system!

Trainer: [[User:wichers | Dave Wichers]], [http://www.aspectsecurity.com Aspect Security] - [[OWASP_AppSec_Europe_2008_-_Belgium/Training#T4._Building_Secure_Web_Services_-_2-Day_Course_-_May_19-20,_2008 | Read more here!]]
|-
! align="center" style="background:#4058A0; color:white" | T5. Open Source ModSecurity Training
|-
| style="background:#F2F2F2" | ModSecurity is currently the most widely deployed web application firewall (WAF) product. This two-day class is for those people who want to learn how to build, deploy, and use ModSecurity in the most effective manner. The course will cover the open source ModSecurity Console, which helps manage alerts on suspicious web activity targeting your web servers. The course also provides an in-depth look at the extremely powerful ModSecurity Rules Language.

Trainer: Ryan Barnett, Breach - [[OWASP_AppSec_Europe_2008_-_Belgium/Training#T5._ModSecurity_Boot-Camp_Training_-_2-Day_Course_-_May_19-20,_2008 | Read more here!]]
|}
More information about the tutorials are [[OWASP_AppSec_Europe_2008_-_Belgium/Training | online]].

Venue: Monasterium PoortAckere, Oude Houtlei 56, 9000 Gent [http://www.monasterium.be/ http://www.monasterium.be/]

==Cocktail Party - May 20, sponsored by Breach Security==

In what is also becoming a tradition, there will be a cocktail party the night before the conference begins, sponsored by Breach Security. The free and open for all conference attendees event will be held at the Vintage Wine Bar at 6:30pm. We would appreciate it if you let us know if you are coming so we can be ready, please mail ofers@breach.com to confirm.

[[Media:AppSec_EU_2008_Breach_Party.pdf|Details and direction map]] (updated May 7th with map and instructions from Monasterium Poortackere, the location of the training classes)

==Evening Social Event - May 21==

At every conference we have an evening social event the first night. This allows participants to have some unstructured time to mingle with the other attendees. They are always fun and typically attract about half the conference attendees. This year's event will be a Flemish buffet with special Belgian beers at the Monasterium (near the conference location).

Registration is available via the OWASP Conference Cvent site at: [http://guest.cvent.com/i.aspx?4W,M3,7b36ecdc-1234-4d63-bc08-898a7bf60b2a Cvent link]

==OWASP Band - May 21, sponsored by Breach Security ==

If that is not enough: tune in for the OWASP Band! Check out the vibes of last year [[OWASP Band | online]]. After the OWASP Dinner you can play, dance or listen to the greatest open-source band: THE OWASP Band. You play an instrument; the neighbours don't complain on your singing talents: contact dinis.cruz <at> owasp.org!

Venue: [http://www.whitecatbelgium.com/ The White Cat]
Time: 23h

Be there, or be ...

==Accommodations==

* OWASP arranged for a room block of 20 Executive Deluxe rooms at the [http://www.nh-hotels.com/nh/en/hotels/belgium/ghent/nh-gent-belfort.html NH Gent Belfort] at a rate of €199 per night. This room block is being held through April 11!! After that date, there is no guarantee that rooms at this rate will be available at the NH Gent Belfort.
* OWASP attendees have an option for 20 rooms at € 122 and 10 rooms at € 132 per night at the [http://www.monasterium.be Hotel Monasterium PoortAckere] up until April 30. Use OWASP as reference when booking your room. Please note that there are no more rooms for the night of May 22.
* OWASP arranged for a room block of 25 rooms at the IBIS hotels. You can already contact them on [http://www.ibishotel.com/ibis/fichehotel/gb/ibi/1455/fiche_hotel.shtml Hotel Ibis Gent Centrum Opera] (€ 89 per night - 10 rooms) and [http://www.ibishotel.com/ibis/fichehotel/gb/ibi/0961/fiche_hotel.shtml Hotel Ibis Gent Centrum Kathedraal] (€ 99 per night - 15 rooms of which 3 still available for the 22nd) - reservations through e-mail: H0961-RE at accor.com or fax: 0032/9 233 10 00 (before April 19 - reference OWASP).

It is difficult getting rooms at reduced prices, as there is a medical congress around the same time in Ghent. You will find it difficult to get a room for the night of May 22. We recommend you then book a room for one night near the airport of [http://maps.google.com/maps?f=q&hl=en&geocode=&q=hotels+zaventem,+belgium&ie=UTF8&z=11 Brussels].

The following is a list of nearby accommodations that may have availability:

* [http://www.gent.be/eCache/THE/44/235.html List of hotels in Ghent]
* [http://www.hotelnazareth.be/ Hotel Vandervalken Nazareth - on Highway 5 minutes from Ghent]
* [http://www.bedandbreakfast-gent.be/en/home.php A list of bed and breakfasts in Ghent]
* [http://www.jeugdherbergen.be/jeugdherbergen/gent/ Youth hostels in Ghent]

==Transportation to the Conference==
If you are flying in you'll come through [http://www.brusselsairport.be Brussels Airport]. From there it is 65 km to Ghent. The airport train station is located below the terminal (basement level-1). Up to 4 trains an hour connect the airport to Brussels North, Brussels Central and Brussels Midi stations. The easiest way is then to take the train to Ghent Sint-Pieters (directly or through Brussels).

To travel by train to the conferene come through Gent Sint-Pieters, see the [http://www.b-rail.be/main/E/ Belgian Railways Website].

'''Next Tuesday May 20th, the Belgian railway is on strike!''' If you are flying in towards Brussels Airport, There will be long queues for the taxis. I advise to contact airport transport beforehand to reserve a place upfront. Possible services to and from Ghent are:
* [http://www.taxi2airport.be/ http://www.taxi2airport.be/]
* [http://www.palitax.be/ http://www.palitax.be/]
* [http://www.taxi-eurojet.be/ http://www.taxi-eurojet.be/]
If you are travelling with HST like Eurostar or Thalys: check with them it they will ride.

From Ghent Sint-Pieters station tram nr 1 (direction Evergem Brielken) is the quickest and most comfortable way to travel to the city centre (stop KORTE MEER: from there it is a 150m walk to the Ghent Aula). The transport system is Ghent is excellent and always on time. A single ticket costs € 1.50 if bought in the bus/tram or € 1.20 if bought from ticket machine of small kiosk called lijnwinkel, such ticket is valid for an hour's travel on all trams and buses.

If you are coming by car, Ghent can be reached through the E40 and the E17. There are 2 parkings nearby: Parking Korte Meer and Parking Kouter.

==Registration and Conference Fees==

Registration is available via the OWASP Conference Cvent site at: [http://guest.cvent.com/i.aspx?4W,M3,7b36ecdc-1234-4d63-bc08-898a7bf60b2a Cvent link]

The conference fee for this conference is :

* Standard: 350 Euros, OWASP Members: 300 Euros, Students: 225 Euros.
* Conference Dinner (Evening of May 21st): 50 Euros
* Conference Tutorials: 825 Euros, Student Fee: 430 Euros
* [http://2008.confidence.org.pl/ CONFidence Poland 2008] members get a € 35 reduction on OWASP (see OWASP On a Plane below).
* [http://www.issa-be.org ISSA], [http://www.isaca.be ISACA] and [http://www.lsec.be L-SEC] Members get a € 35 reduction.

Note: To save on processing expenses, all fees paid for the OWASP conference are non-refundable. OWASP can accomodate transfers of registrations from one person to another, if such an adjustment becomes necessary.

==OWASP on a Plane - CONFidence 2008==
This year's [http://2008.confidence.org.pl/lang-pref/en/ CONFidence 2008] will take place on 16-17.05.2008 in Cracow (Poland). They have decided to spend Saturday morning talking about OWASP-related projects. No more excuses: you can attend 2 OWASP events in a row in Europe!

==Conference Committee==

OWASP Conferences Chair: Dave Wichers - Aspect Security - dave.wichers 'at' owasp.org

2008 EU Planning Committee Chair: Sebastien Deleersnyder - Telindus - seba 'at' owasp.org

Vendor Exhibition Chair: Pravir Chandra - Cigital - chandra 'at' cigital.com

Capture the Flag Chair: Pieter Danhieux - Ernst & Young - pieter.danhieux 'at' be.ey.com

Refereed Papers Chair: Lieven Desmet - KU Leuven - Lieven.Desmet 'at' cs.kuleuven.ac.be

== Affiliated Partners ==
We are glad to have the local support of:
* ISACA
* ISSA
* L-SEC
* Katholieke Universiteit Leuven

==[[OWASP AppSec Conference Sponsors | Conference Sponsors]]==

The following organizations are sponsors for this conference. If you are interested in sponsoring an OWASP conference, please contact OWASP at: conferences 'at' owasp.org.

[http://www.aspectsecurity.com https://www.owasp.org/images/d/d1/Aspect_logo.gif]
[http://www.telindus.com https://www.owasp.org/images/b/b3/Telindus.jpg]
[http://www.imperva.com/ https://www.owasp.org/images/d/de/Imperva_2color_RGB.jpg]
[http://www.fortifysoftware.com https://www.owasp.org/images/a/ac/Fortify.jpg]
[http://www.ibm.com https://www.owasp.org/images/2/2a/IBM_logo_black.jpg]

More information about conference sponsorship is available [[OWASP AppSec Conference Sponsors | here]].

[[Category:OWASP AppSec Conference]]

File:AppSecEU08-BPWAF.pdf

2008-05-21T13:23:17Z

AlexanderMeisel: Presentation held by Alexander Meisel

Presentation held by Alexander Meisel

OWASP AppSec Europe 2008 - Belgium

2008-04-01T08:38:00Z

AlexanderMeisel: Added link to "Best Practices: Web Application Firewalls" talk / Updated Talk title

AppSecEU08 Best Practices Guide Web Application Firewalls

2008-04-01T08:29:05Z

AlexanderMeisel: New page: = preliminary Abstract = This talk is about the paper "Best Practices Guide: Web Application Firewalls" the OWASP German chapter has put together to give a better understanding in how and...

= preliminary Abstract =

This talk is about the paper "Best Practices Guide: Web Application Firewalls" the OWASP German chapter
has put together to give a better understanding in how and where Web Application Firewalls should be use used.

= Speaker Bio =

Alexander Meisel is CTO and founder of 'art of defence'. He is in charge of product development, professional services and support.

His interest and expertise in the area of security dates back to his thesis in which he wrote about avoiding and tracing distributed denial-of-service attacks. He worked for a Swiss IT service provider as a Web security expert; later he joined LINX, Europe’s largest Internet exchange, where he took care of member network security issues. After working for three years as a senior consultant designing and implementing large Web farms, including security audits with a leading producer of web servers, Alexander switched to a SPX Corporation company, where he was the main project manager for Web application solutions in the SAP area.

Germany

2008-02-25T14:17:38Z

AlexanderMeisel: /* OWASP German Chapter Meeting - February 20th in Darmstadt */

{{Chapter Template|chaptername=Germany|extra=The chapter lead is [[user:tgondrom| Tobias Gondrom]]. Chapter Board members are: Thomas Schreiber, Holger Heimann and Boris Hemkemeier. |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-germany|emailarchives=http://lists.owasp.org/pipermail/owasp-germany}}

== Next OWASP German Chapter Meeting ==
The next chapter meeting has not been announced yet

'''Date: tbc''' 
'''Location: tbc''' 
'''Agenda: tbc'''
 

== Past Events ==

=== OWASP German Chapter Meeting - February 20th in Darmstadt ===
'''Date: February 20th, 2007, 11:00-16:15''' 
'''Location: Darmstadt, CAST (http://www.cast-forum.de)''' 
Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt] 
 

The next chapter meeting will be hosted at CAST in Darmstadt. 
This time the focus is on technical presentations and discussion. 
 
'''Agenda'''
Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion.
* 1. (11:00 - 11:15) Welcome, Introduction and Administrativia
* 2. (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann)
* 3. (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom)
* 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)
* 5. (12:30 - 13:15) Break
* 6. (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann)
* 7. (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss)
** "Input validation in ASP.NET -- tips, tricks & pitfalls" (Boris Hemkemeier)
** "Managing of extremely large Web Application Firewall Installations" (Slides: [http://www.owasp.org/images/f/f6/VeryLargeWAFs.pdf PDF]) (Alexander Meisel)
* 8. (14:45 - 15:00) Coffee Break
* 9. (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias)
* 10. (15:45 - 16:00) Wrap-up and outlook
 

=== Chapter Meeting on September 7th 2007 in Frankfurt/Main ===

After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00.

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.

''' [https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html Read meeting notes/minutes here]'''

====comments====

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 [[user:tgondrom| Tobias]] or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list (now working!)].

== Local News ==
* 07 September 2007: Chapter meeting in Frankfurt
* 18 July 2007: scheduled chapter meeting on September 7th 2007
* 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').

* 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').

* 06 Sept 2006: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.de/literat/studien/websec/WebSec.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] (engl: 'Measures and Best Practices for Web Application Security').

'''OWASP Moves to MediaWiki Portal - 11:05, 20 May 2006 (EDT)'''

OWASP is pleased to announce the arrival of OWASP 2.0!

OWASP 2.0 utilizes the MediaWiki portal to manage and provide
the latest OWASP related information. Enjoy!

File:WAF-Paper.pdf

2008-02-25T14:15:32Z

AlexanderMeisel: First presentation of the proposed best practices WAF paper

First presentation of the proposed best practices WAF paper

File:VeryLargeWAFs.pdf

2008-02-25T14:08:18Z

AlexanderMeisel: Keynote presentation export to PDF

Keynote presentation export to PDF

Germany

2008-02-25T14:01:57Z

AlexanderMeisel: /* Past Events */

{{Chapter Template|chaptername=Germany|extra=The chapter lead is [[user:tgondrom| Tobias Gondrom]]. Chapter Board members are: Thomas Schreiber, Holger Heimann and Boris Hemkemeier. |mailinglistsite=http://lists.owasp.org/mailman/listinfo/owasp-germany|emailarchives=http://lists.owasp.org/pipermail/owasp-germany}}

== Next OWASP German Chapter Meeting ==
The next chapter meeting has not been announced yet

'''Date: tbc''' 
'''Location: tbc''' 
'''Agenda: tbc'''
 

== Past Events ==

=== OWASP German Chapter Meeting - February 20th in Darmstadt ===
'''Date: February 20th, 2007, 11:00-16:15''' 
'''Location: Darmstadt, CAST (http://www.cast-forum.de)''' 
Fraunhoferstr. 5 (vormals Rundeturmstr. 6) - EG Room 072 - [http://www.cast-forum.de/workshops/anfahrt.html Anfahrt] 
 

The next chapter meeting will be hosted at CAST in Darmstadt. 
This time the focus is on technical presentations and discussion. 
 
'''Agenda'''
Technical presentation slots will consist of 20-30 minute presentation and 15 minute discussion.
* 1. (11:00 - 11:15) Welcome, Introduction and Administrativia
* 2. (11:15 - 11:30) Vorstellung von CAST (Dr. Heinemann)
* 3. (11:30 - 11:45) Short OWASP organisation introduction and update (Tobias Gondrom)
* 4. (11:45 - 12:30) First technical presentation "Best Practices beim Einsatz einer Web Application Firewall 1.0" (Alexander Meisel)
* 5. (12:30 - 13:15) Break
* 6. (13:15 - 14:00) Second technical presentation "Defending against Web Application DoS Attacks" (Maximilian Dermann)
* 7. (14:00 - 14:45) 20-Minutes Talks (15 Min Presentation + 5-10 Min Discuss)
** "Input validation in ASP.NET -- tips, tricks & pitfalls" (Boris Hemkemeier)
** "Managing of extremely large Web Application Firewall Installations" (Alexander Meisel)
* 8. (14:45 - 15:00) Coffee Break
* 9. (15:00 - 15:45) Fourth technical presentation "Secure Coding and Development Guidelines (part of CLASP)" (Tobias)
* 10. (15:45 - 16:00) Wrap-up and outlook
 

=== Chapter Meeting on September 7th 2007 in Frankfurt/Main ===

After two years of absence the German Chapter has been restarted. The chapter meeting was on September 7th 2007, 15:00 - 18:00.

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.

''' [https://lists.owasp.org/pipermail/owasp-germany/2007-September/000038.html Read meeting notes/minutes here]'''

====comments====

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 [[user:tgondrom| Tobias]] or send an email to our [mailto:owasp-germany@lists.owasp.org chapter mailing list (now working!)].

== Local News ==
* 07 September 2007: Chapter meeting in Frankfurt
* 18 July 2007: scheduled chapter meeting on September 7th 2007
* 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').

* 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').

* 06 Sept 2006: German Federal Office for Information Security aka ''Bundesamt für Sicherheit in der Informationstechnik (BSI)'' has released the [http://www.bsi.de/literat/studien/websec/WebSec.pdf Maßnahmenkatalog und Best Practices für die Sicherheit von Webanwendungen] (engl: 'Measures and Best Practices for Web Application Security').

'''OWASP Moves to MediaWiki Portal - 11:05, 20 May 2006 (EDT)'''

OWASP is pleased to announce the arrival of OWASP 2.0!

OWASP 2.0 utilizes the MediaWiki portal to manage and provide
the latest OWASP related information. Enjoy!

Germany

2008-02-25T14:00:33Z

AlexanderMeisel: /* Next OWASP German Chapter Meeting - February 20th in Darmstadt */