Phoenix

Local News
New pages on Phoenix/Tools and Phoenix/ToolsProfile

 Phoenix OWASP Day on Sept 6th is cancelled - we will have our normal meeting this month, Thurs Sept. 13th.

Andre Gironda (Dre), the originator of Phoenix/Tools, moved to Chicago. Best of luck, Dre!

[mailto:jrose@owasp.org Jon Rose] was previously the co-leader but recently moved to the Washington, DC area. Best of luck, Jon!

At the chapter meeting on January 11th, 2007 we discussed the possibility of comparing tools. Jon Rose presented the idea that we do round-table discussions on rating web application vulnerability assessment tools that we use. Andre Gironda suggested that we put the tools into categories and benchmark for performance in addition to evaluating the potential/easiness of vulnerability discovery.

There is a page on Phoenix/Tools with a near-complete and up-to-date list of WAVA Tools. If you find that a tool is not on the list, feel free to add it. However, the list will not be updated until the ToolsProfile project nears completion (or at least once per month).

Instead of subjectively choosing which tools to focus on, we will focus on what tools we actually use in daily/weekly assessment work. By completing profiles on what tools we individually use, we can further identify how the tools are being used, why they are being used, and possibly why certain tools are chosen over others. Please see the Phoenix/ToolsProfile page for further information.

Phoenix OWASP - Home of the infamous Phoenix/Tools wiki page

This chapter is dedicated to bringing together local businesses, students, and web and security enthusiasts in order to discuss current events, trends, tools, and offensive/defensive techniques related to web application security. We currently hold meetings every other month, typically with two speakers at each meeting.

Tenative Meeting Schedule:


 * March 8, 2007
 * May 10, 2007
 * July 12, 2007
 * September 13, 2007
 * November 8, 2007

What talks would you like to see?
Please Update


 * Certificates
 * Application Firewalls
 * PHP
 * Security ROI
 * Penetration Testing Methods
 * AJAX
 * Cryptography in Web Applications
 * Reversing ActiveX controls
 * Using Local Proxies
 * Browser Safety / Security
 * Web services security: XML/SOAP/WSDL

Where
UAT - University of Advancing Technology

Auditorium

2625 West Baseline Road

Tempe, Arizona

85283-1056

Entrance back of building

We are NOT meeting in the auditorium this time - UAT has a previously scheduled event there. They are giving us a different room - stay tuned to this page for more information, or join out Mailing List.... http://lists.owasp.org/mailman/listinfo/owasp-phoenix

When
 8:00 PM Social

Dos Gringos South Tempe Mexigrill 8000 S. Priest Rd Tempe, AZ 85284 Ph: 480.753.4577
 * New Location**

This is just South of Elliot & Priest.

http://www.google.com/maps?q=8000+S+Priest+Dr,+Tempe,+AZ+85284,+USA&sa=X&oi=map&ct=title

Let us know if you have any questions or comments on the mailing-list.

Previous Meetings
'''Application Security Tools - Web Application Proxy Editors and Scanners - Andre Gironda - Adam Muntner Risk Assessment Considerations for Web Applications (brief talk+discussion) - Erich Newell'''

 – and other web+network trust issues – Andre Gironda

In computing, the same origin policy is an important security measure for client-side scripting (mostly Javascript). It prevents a document or script loaded from one "origin" from getting or setting properties of a document from a different "origin". It was designed to protect browsers from executing code from external websites, which could be malicious.

XSS and CSRF vulnerabilities exploit trust shared between a user and a website by circumventing the same-domain policy. DNS Pinning didn't pan out exactly right, either. Can client-side scripting allow malicious code to get into your browser history and cache? Can it enumerate what plugins you have installed in your browser, or even programs you have installed to your computer? Can it access and modify files on your local hard drive or other connected filesystems? Can client-side scripts be used to access and control everything you access online? Can it be used to scan and attack your Intranet / local network? Does an attacker have to target you in order to pull off one of these attacks successfully? If I turn off Javascript or use NoScript, am I safe? What other trust relationships does the web application n-Tier model break?

Data@Risk – Protecting Web Applications Throughout the Development Lifecycle from Hackers - Brian Christian

Brian Christian, Co-founder and Application Security Engineer, S.P.I. Dynamics, Inc. discussed what Web application security is and why it is needed throughout the entire development lifecycle. We will discuss common vulnerabilities in the Web application layer and why they are so easily exploited. This session demonstrates how to defend against common attacks at the Web application layer with examples covering Web application hacking methods such as SQL Injection, Blind SQL Injection, Cross-Site Scripting (XSS), Parameter Manipulation, etc. We will also review how compliance and regulatory legislation such as PCI, GLBA, HIPAA, CASB 1386, and Sarbanes-Oxley, etc. specifically relates to and affects Web application security. Additionally, we will examine how security throughout the development lifecycle is essential to the security of Web application code and the protection of proprietary data.

Web Application 0-Day – Jon Rose

Learn about how to identify, exploit, and remediate some of the most common security vulnerabilities in web applications. We’ll be using real-world examples in a dynamic, fun, and open discussion using publicly available source code.

Discovering Web Application Vulnerabilities with Google CodeSearch

Building Application Security into the SDLC - Adam Muntner

Adam will share his experiences about how organizations can integrate application security into all phases of the Software Development Life Cycle, from the creation of functional specifications all the way through deployment, maintenance, and updates. He will explain how to "bake security in" rather than "ice it on."