Chicago

Welcome to the OWASP Chicago Local Chapter

Anyone in our area interested in information security is welcome to attend. Our meetings are informal and encourage open discussion of all aspects of application security. We invite attendees to give short presentations about specific topics.

If you have any questions about the Chicago chapter, please send an email to our chapter leaders, Joe Bernik, Cory Scott, or Jason Witty.

The Chicago chapter is sponsored by LaSalle Bank[1]

Next Meeting

The next Quarterly Chicago OWASP Chapter meeting will be held on September 5th, 2007 at 6PM CST.

We hope to see you at the ABN AMRO Plaza at 540 W. Madison, Downtown Chicago, 23rd floor. Please RSVP to jason{AT}wittys.com by Monday 09/03/2007 if you plan to attend. Your name will need to be entered into the building's security system in order to gain access to the meeting.

Agenda:

6:00 Refreshments and Networking
6:30 Andre Gironda - Automated Thrash Testing
7:15 Yet to be Named Presentation

Presentation Abstracts

Andre Gironda - Automated Thrash Testing Andre Gironda is a member of the OWASP Tools Project team. He recently made contributions to the OWASP Top Ten 2007, and has spoken at local OWASP events on topics ranging from automated scanning tools to problems with trusting the same-origin policy. After building the Phoenix Tools page - a long list of mostly free tools sorted by classification - he intends to get the word out about both automated and manual tools/techniques that can really make a difference when testing web applications for security.

Automated Thrash Testing introduces some novel ways of accurately testing both server-side and client-side web applications according to simple standards with simple tools that can be used by both penetration testers and developers. The "thrash" component means to test extensively and with completeness. The problem for thrash testing completeness is to measure test coverage. Test coverage of any web application should be accurately gauged by the amount of web surface area covered (pages, links, elements), as well as the actual code coverage itself.

As of today, web applications on the client-side have not been sufficiently tested. Protocol drivers, found in all generations of webapp scanners, aren't capable of testing client-side code - partly due to their reliance on domain-specific frameworks. Application drivers had to be created to include all of the application functionality of a modern browser. Some new tools have even been built into the browser itself. This leads to another problem of using a different tool for every browser. The most recent application drivers have been built to work with multiple browsers in a more standardized way, allowing for better automation in testing.

Automated Thrash Testing is meant to be a call to action for a web application vulnerability scanner standard. Compare to similar work by Sutton, Greene, and Amini in Requirements for Effective Fuzzing. It is planned to encompass the entirety of OWASP Top Ten 2007 and WASC TC v2, but the focus of the talk is on how the tools and methods should work - not which attack vectors they should include or how those specific attacks function.

Presentation Archives

[2]Webapps In Name Only Thomas Ptacek, Matasano Security

Where modern network architecture meets legacy application design, we get "The Port 80 Problem": vendors wrapping every conceivable network protocol in a series of POSTs and calling them "safe". These "Webapps In Name Only" are a nightmare for application security specialists.

In this talk, we'll discuss, with case studies, how tools from protocol reverse engineering can be brought to bear on web application security, covering the following areas:

- Locating and Decompiling Java and .NET Code - Structure and Interpretation of Binary Protocols in HTTP - Protocol Debugging Tools - Web App Crypto Tricks

[3]Token-less strong authentication for web applications: A Security Review Cory Scott, ABN AMRO

A short presentation on the threat models and attack vectors for token-less schemes used to reduce the risk of password-only authentication, but yet do not implement "true" two-factor technologies for logistical costs or user acceptance reasons. We'll go over how device fingerprinting and IP geo-location work and discuss the pros and cons of the solutions.