This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Chicago"
(→Next Meeting) |
(→Next Meeting) |
||
| Line 21: | Line 21: | ||
6:00 Refreshments and Networking<br> | 6:00 Refreshments and Networking<br> | ||
6:30 '''Integrating Security Into the QA Group''' - Taylor McKinley, Product Manager at Fortify Software<br> | 6:30 '''Integrating Security Into the QA Group''' - Taylor McKinley, Product Manager at Fortify Software<br> | ||
| − | 7:10 | + | 7:10 '''Web app penetration testing with scripting languages''' - Mike Tracy, Security Consultant at Matasano Security |
| − | Presentation abstracts | + | Presentation abstracts |
| − | + | '''Integrating Security Into the QA Group''' | |
Until recently, Web Application Testing was left to security teams and ethical hackers who used advanced tools, such as Web application scanners, to analyze running Web applications. However, security groups are becoming overburdened by product releases, and many organizations are attempting to move security testing earlier in the development cycle. The QA group is a natural candidate, since it generally has the infrastructure in place to test applications for quality issues. However, for many organizations, integrating security into the QA group has been incredibly difficult. The process of running a security test is a learned skill, and not something one can teach a QA tester in a matter of days. On top of that, most security testing tools were designed for penetration testers (since they require an in-depth knowledge of application security theory) and are not generally usable by QA professionals. As a result, very few QA groups have successfully adopted security testing. | Until recently, Web Application Testing was left to security teams and ethical hackers who used advanced tools, such as Web application scanners, to analyze running Web applications. However, security groups are becoming overburdened by product releases, and many organizations are attempting to move security testing earlier in the development cycle. The QA group is a natural candidate, since it generally has the infrastructure in place to test applications for quality issues. However, for many organizations, integrating security into the QA group has been incredibly difficult. The process of running a security test is a learned skill, and not something one can teach a QA tester in a matter of days. On top of that, most security testing tools were designed for penetration testers (since they require an in-depth knowledge of application security theory) and are not generally usable by QA professionals. As a result, very few QA groups have successfully adopted security testing. | ||
| Line 32: | Line 32: | ||
This talk will focus on a new technique for allowing QA teams to participate in the security process without any additional work or expertise. | This talk will focus on a new technique for allowing QA teams to participate in the security process without any additional work or expertise. | ||
| − | Web app penetration testing with scripting languages | + | '''Web app penetration testing with scripting languages''' |
We show how, with minimal scripting knowledge, using tools we're | We show how, with minimal scripting knowledge, using tools we're | ||
Revision as of 05:23, 18 January 2008
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 take place on March 5th, 2008 at 6pm CDT.
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 3/3/2008 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 Integrating Security Into the QA Group - Taylor McKinley, Product Manager at Fortify Software
7:10 Web app penetration testing with scripting languages - Mike Tracy, Security Consultant at Matasano Security
Presentation abstracts
Integrating Security Into the QA Group
Until recently, Web Application Testing was left to security teams and ethical hackers who used advanced tools, such as Web application scanners, to analyze running Web applications. However, security groups are becoming overburdened by product releases, and many organizations are attempting to move security testing earlier in the development cycle. The QA group is a natural candidate, since it generally has the infrastructure in place to test applications for quality issues. However, for many organizations, integrating security into the QA group has been incredibly difficult. The process of running a security test is a learned skill, and not something one can teach a QA tester in a matter of days. On top of that, most security testing tools were designed for penetration testers (since they require an in-depth knowledge of application security theory) and are not generally usable by QA professionals. As a result, very few QA groups have successfully adopted security testing.
This talk will focus on a new technique for allowing QA teams to participate in the security process without any additional work or expertise.
Web app penetration testing with scripting languages
We show how, with minimal scripting knowledge, using tools we're developing in-house and releasing to the public, the browser/proxy/tool mechanisms we use to test web apps today can be enhanced. With a little scripting, your test tools can be customized to any project, handle Ajax sites, JSON documents, XML, and more.
We introduce PenTestConsole, a set of Ruby classes wrapped around an HTML parser (Hpricot), an XML parser (REXML), a deep spider, a fuzzer and classes that provide http functionality that would normally be used in a vulnerability assessment tool (forms, parameters, header manipulation, character encoding etc.). We started out by looking at URL transfer libraries (Curb Ruby bindings for libcurl and Ruby net/http), parsers (Hpricot) and fully blown scraping tools (like Mechanize) and decided to create something new. We wanted a tool could range from fine-grained manipulation of user inputs to hit it with a hammer random acts of senseless garbage. We also wanted to be able to do combinatoric input reduction (pairwise for example) and header manipulation and tie it right into the tool.
We discuss how we leverage minimal programming effort to gain maximal improvement in testing, so that we're no longer held hostage by web app pen testing tools (no matter how good they are), and so that we can automate and accelerate tests.
Presentation Archives
Automated Thrash Testing - Andre Gironda - Presentation slides here
Defeating Information Leak Prevention - Eric Monti - Presentation slides here
[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.
