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 "OWASP AU Conference 2009 Presentations"
Line 136: | Line 136: | ||
"Securing applications insecurely gives a false sense of security. This session shows how popular security defenses are implemented wrongly, how apps are fitted with wooden swords and plastic guns. Based on our experience of testing 300+ applications, we show the most common errors in security defenses like CAPTCHAs, Encryption, Cache Control, etc. | "Securing applications insecurely gives a false sense of security. This session shows how popular security defenses are implemented wrongly, how apps are fitted with wooden swords and plastic guns. Based on our experience of testing 300+ applications, we show the most common errors in security defenses like CAPTCHAs, Encryption, Cache Control, etc. | ||
Using code snippets and demos, we present actual encounters with insecurely secured applications. The audience will see how insecure implementations of CAPTCHAs allow bots to comfortably bypass defenses and perform automated registrations, post feedback, flood surveys and much more. We take you on a walk-through of how various insecure implementations of hashing defeats its very purpose. The audience learns how wrong use of cache control tags leads to authentication bypass, and disclosure of information among other weaknesses. We show how these wooden swords are a cause for concern. We explain what developers need to keep in mind so they implement security techniques "securely" - learn how to avoid subtle errors, and do things right the first time. With each topic we conclude with implementation best practices so developers / project managers / application owners can practice it from their next day at work." | Using code snippets and demos, we present actual encounters with insecurely secured applications. The audience will see how insecure implementations of CAPTCHAs allow bots to comfortably bypass defenses and perform automated registrations, post feedback, flood surveys and much more. We take you on a walk-through of how various insecure implementations of hashing defeats its very purpose. The audience learns how wrong use of cache control tags leads to authentication bypass, and disclosure of information among other weaknesses. We show how these wooden swords are a cause for concern. We explain what developers need to keep in mind so they implement security techniques "securely" - learn how to avoid subtle errors, and do things right the first time. With each topic we conclude with implementation best practices so developers / project managers / application owners can practice it from their next day at work." | ||
+ | |||
+ | == Tom Brennan == | ||
+ | '''OWASP 3.0 - Where we came from, where we are, where we are going.''' |
Revision as of 03:06, 11 January 2009
![]() |
Presentations
The following presentation abstracts are provided to understand the details of the presentations. This year OWASP will be video recording the event again and all videos will be kept online and available through the OWASP wiki.
Christian Heinrich
TCP Input Text & Download Indexed Cache
To be provided.
Andrew Vanderstock
The future (and past) of web application security: how to detect and protect against value attacks.
2008 was a bumper year for value attacks. Criminals are finally getting over the sophomoric desire to 0wn large numbers of hosts, turning their attention to getting a lot of money instead. This is bad if you have stuff the criminals want.
Unfortunately, web application scanners (source and dynamic) cannot easily (if at all) detect or scan for this entire class of attack - you need to do the hard work.
In this presentation, you'll learn how to:
- Figure out where the value in your application is
- Identify weaknesses in your processes by identifying all the paths to your assets
- Protect your application against value and process attacks by careful and minor changes to your design
- Identify if folks are trying to do "interesting" things using ESAPI's intrusion detector classes
With some luck, there might even be a demo!
Andrew van der Stock is a leading web application researcher active in the builder web application community. Andrew has recently returned from a two year stint working in the USA.
Andrew is the project lead and lead author for the following OWASP projects:
- OWASP Developer Guide 3.0
- OWASP Top 10 2009
- ESAPI for PHP port
He is looking for contributors to all of the above projects. He helped start the Melbourne and Sydney OWASP chapters. Previously, Andrew was Executive Director of OWASP from 2005 to 2007.
He is the moderator of [email protected], and has contributed the web application section of the SANS Top 20 since 2005. He helped set the SANS GSSP Secure Programmer (Java) certification, and thus is deemed to hold this certification as he literally knows all the answers (he peeked).
In previous lives, he has assisted with the following open source projects:
* UltimaBB, forum software - fork of XMB * XMB, forum software * SAGE-AU President of SAGE AU in 2000-2001, General Committee member 1999-2000, and a long time member. * pnm2ppa HP print drivers for Unix and work-alike systems * XFree86 Device drivers for Matrox Millennium I/II/Mystique (mid 90's vintage stuff)
In his now copious spare time, Andrew continues to run AussieVeeDubbers, one of Australia's largest car forums, and one of the world's largest VW car forums.
Ranjita Shankar Iyer
A Prescriptive approach to Secure SDLC
The old adage goes “Prevention is better than cure”. Similarly, many security vulnerabilities can be easily prevented if security was taken into consideration at the beginning of the development process. As application security professionals, we’ve seen that uncovering serious vulnerabilities and subsequent attempts to repair with production-ready applications significantly increase costs to the enterprise and delay project timelines. Moreover, despite the immense amount of literature on application vulnerabilities we find that developers are still unaware or only have very limited knowledge of common threats and secure coding practices. This often leads to the commonly sighted flaws such as the following: - Implementation of client-side controls only that are easily bypassed - Incorrect implementation of regular expressions to block XSS and SQL injection attacks - Including too much sensitive business logic in applications that utilize FLEX and other RIA technologies - Insecure use of API's and frameworks such as struts and spring There are a number of commercial secure coding tools that facilitate developers to incorporate security controls upfront during the development and build process, but commercial products tend to be expensive, and not practical to provide to every developer. Commercial products are also a black-box to developers and enterprise security teams, where it’s unclear on how vulnerabilities were identified.
Leveraging our expertise in the field, we have developed an extensive data grid that maps standard security requirements (grouped into categories such as User Authentication, Input Validation, Session Management etc ) to sample implementation snippets in popular frameworks such as .Net, Java Struts and FLEX. This data grid draws on work already complied by open source communities such as OWASP that has a variety of tools and resources to help developers in understanding and resolving security issues. Furthermore the major frameworks mentioned above also often provide a large set of security APIs at the developer’s disposal. Leveraging these existing APIs lessens the burden of implementing security correctly and our data grid references these API's where appropriate.
However, experience has shown us that such resources alone are not effective in preventing security code flaws. Therefore we are launching an open-source, extensible, secure coding analysis tool that delivers information from the data grid to the developer as they are writing code in their favorite IDE's. The plug-in tool takes a prescriptive approach and prompts the developer with useful information and repair techniques using existing security APIs within major frameworks and open-source resources, such as ESAPI. The tool has an innovative extensible design, whereby modules can be easily extended to incorporate any framework and any vulnerability. Deliberate design decisions have been made to accommodate future frameworks and the customizable vulnerability identification engine can also be tailored to accommodate specific business risks and regulatory policy requirements.
Speaker Bio's
1) Ranjita Shankar Iyer CISSP, GSEC Application Security Architect - Morgan Stanley Ranjita is an application security specialist with over 8 years of experience developing and securing business critical applications. She is currently a Security Architect at Morgan Stanley and assesses complex applications across the firm to ensure that they are employing appropriate security controls to protect highly confidential client and employee data. Prior to this, she was at EY at the Advanced Security Center performing attack and penetration tests for fortune 100 financial services clients. She is well versed in the many challenges that organizations face with regards to introducing security into the software development lifecycle.
2) Kai Huang CISSP, GSEC Application Security Specialist - Ernst & Young Kai is part of E&Y Global Information Security group, and is responsible for reviewing and advising security matters for a wide range of applications and information systems consumed by E&Y. Prior to GIS, Kai was a member of the E&Y Advanced Security Center, performing web application, internet, intranet tests for EY's Fortune 500 clients. Kai's primary areas of interest are web application security and VOIP research and tool development. Prior to E&Y, Kai worked at CIGNA as a CIRT member.
Ann Marie Westgate
Web Application Security and the PA-DSS
The Payment Card Industry's (PCI) Payment Application Data Security Standards (PA-DSS) version 1.2 was released in November 2008, and has implications for every payment application vendor whose product is sold, distributed, or licensed without customization for a specific client. This discussion will begin with a brief description of the PA-DSS and the differences between PA and PCI. We will then provide a soft introduction to the payment application audit procedures and will match PA requirements to each phase of the software development lifecycle. Since the audit procedures are written for the PA-QSA and not the subject of audit, it can be daunting to the application vendor. Instead we will present most of the requirements listed in the PA-DSS relative to the following stages: Project Initiation and Planning Definition and Design Development Testing Deployment Maintenance and Operations The objective is to inform various team members of their roles and responsibilities in creating secure payment applications throughout the application’s lifecycle, and ultimately in passing a PA audit. Using our experience in performing Payment Application assessments, we will address key requirements that cause the most concern and confusion to vendors. This talk will include deadlines specific to Australia / Asia Pacific as published by credit card companies, and where to find PA-QSAs that audit payment applications in these regions. The target audience is web application developers, testers, vendors, or anyone interested in PCI and Payment Application requirements. Presenter: AM Westgate M.Sc., B.Ed., CISSP, QSA, PA-QSA BIO: AM brings a range of experience as a security systems analyst, a software engineer and as an information security instructor. She has participated in PCI Compliance engagements and PCI gap assessments. In addition, she has been the primary consultant on PA-DSS Validation, PA gap assessments and remediation engagements. AM has over 5 years experience in security software engineering, and has worked in Canada, USA, Ireland and England. She is an experienced speaker, and a part time instructor of the CISSP preparation course in the continuing education department at a local university. [email protected] Collaborator: Dj Browne, B.ES, CISSP, ISSAP, QSA, PA-QSA BIO: Dj has been involved with a variety of security fields for 18 years, from physical to software development, architecture and audit. He has worked with some of Canada’s largest companies and government organizations on security focused projects including PCI and PA assessments. Dj has contributed to the OWASP Designing Secure Web Applications document and enjoys traveling…to Australia. [email protected]
Peter Frieberg
Determining attack surface and creating security test cases through observing business testing
Application security testing is often a last minute black box activity where security testers rely on gut feel and intuition to determine how a system should work in order to compromise it. Even when coupled with source code analysis, a manual review or specialist software will not see all the data flows and context which pass through a system.
By introducing web proxies that passively capture data flows from User Acceptance Testing we can observe the context of how the application should work. Using a newly created proxy log analysis tool, SPLAT, the following benefits can be obtained: • Automatically determine the attack surface of an application o What URLs are seen by users? o Are these shared between roles? o What pieces of data or parameters are passed and where? • Automatically create test cases for some OWASP Top 10 Vulnerabilities • Determine the data flows within your application • Potentially find disclosure of sensitive information such as credit cards and tax file numbers • Generate comparable metrics from testing phases
Siddharth Anbalahan
Advanced Techniques in Code Reviews
Learn how experts blend manual and automated techniques to accelerate code reviews. When you review large apps, you’ll love these nifty tricks to find famous, and some not-so-famous flaws. Using demos & code snippets we show how the blended technique is better than simple scanning or manual checks. You learn to write custom scripts that slash review time to 1/5th and get a ready-to-use checklist. Session Learning Objectives The 3 learning objectives of the session are: - Learn how to code review large applications efficiently - Learn a structured approach to code reviews - Develop a checklist to use in future code reviews Participants will be able to do code reviews as mandated by PCI for all applications that handle credit card information.
Brett Moore
Vulnerabilities In Action
Common application vulnerabilities have been known for years now, and developers have been told about the threats and how to prevent these flaws. Even so, web applications are still been developed that are vulnerable to some of the oldest and most well known security flaws. The aim of this presentation is to show the attendees how vulnerabilities are discovered and exploited in real world situations, and the devastating effect that a flaw can have on the security of an application. The presentation will demonstrate multiple different application vulnerabilities across various development languages and operating systems. All of the commonly seen vulnerabilities will be demonstrated, aligned with the OWASP top 10 rating system. Attendees will be able to learn about the real dangers that application vulnerabilities pose, by seeing them been exploited as they would in a real compromise situation. The demonstration will be done again a ‘virtual’ network of vulnerable systems that will contain both server and application level flaws, giving a real world insight to an application compromise.
Karmendra Kohli
Wooden Swords and Plastic Guns - Insecure Security Defenses
"Securing applications insecurely gives a false sense of security. This session shows how popular security defenses are implemented wrongly, how apps are fitted with wooden swords and plastic guns. Based on our experience of testing 300+ applications, we show the most common errors in security defenses like CAPTCHAs, Encryption, Cache Control, etc. Using code snippets and demos, we present actual encounters with insecurely secured applications. The audience will see how insecure implementations of CAPTCHAs allow bots to comfortably bypass defenses and perform automated registrations, post feedback, flood surveys and much more. We take you on a walk-through of how various insecure implementations of hashing defeats its very purpose. The audience learns how wrong use of cache control tags leads to authentication bypass, and disclosure of information among other weaknesses. We show how these wooden swords are a cause for concern. We explain what developers need to keep in mind so they implement security techniques "securely" - learn how to avoid subtle errors, and do things right the first time. With each topic we conclude with implementation best practices so developers / project managers / application owners can practice it from their next day at work."
Tom Brennan
OWASP 3.0 - Where we came from, where we are, where we are going.