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 AppSec Research 2010 - Stockholm, Sweden"

From OWASP
Jump to: navigation, search
(Removed early bird info since it's outdated)
(Abstracts, authors, affiliations, and presentation categories for June 23)
Line 125: Line 125:
  
 
==== June 23  ====
 
==== June 23  ====
 
+
<center>
 +
[[Image:OWASP AppSec Research 2010 Research R.gif]] = Research paper [[Image:OWASP AppSec Research 2010 Demo D.gif]] = Demo [[Image:OWASP AppSec Research 2010 Presentation P.gif]] = Presentation
 +
</center>
 
{| border="0" align="center" style="width: 80%;"
 
{| border="0" align="center" style="width: 80%;"
 
|-
 
|-
Line 147: Line 149:
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:10-10:45  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:10-10:45  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | '''BitFlip: Determine a Data's Signature Coverage from within the Application'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] '''BitFlip: Determine a Data's Signature Coverage from within the Application'''  
 
''Henrich Christopher Poehls''<br>  
 
''Henrich Christopher Poehls''<br>  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''CsFire:&nbsp;Browser Enforced Mitigation Against CSRF'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''CsFire:&nbsp;Browser Enforced Mitigation Against CSRF'''  
 
''Lieven&nbsp;Desmet&nbsp;and&nbsp;Philippe&nbsp;De&nbsp;Ryck''<br>  
 
''Lieven&nbsp;Desmet&nbsp;and&nbsp;Philippe&nbsp;De&nbsp;Ryck''<br>  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''Deconstructing ColdFusion'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Deconstructing ColdFusion'''  
 
''Chris Eng''  
 
''Chris Eng''  
  
Line 159: Line 161:
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:45-11:10  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 10:45-11:10  
 
| align="left" colspan="2" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Break - Expo  
 
| align="left" colspan="2" style="width: 90%; background: none repeat scroll 0% 0% rgb(194, 194, 194);" | Break - Expo  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | CTF Kick-Off  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | CTF Kick-Off
 
 
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:10-11:45  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:10-11:45  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | '''Towards Building Secure Web Mashups'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] '''Towards Building Secure Web Mashups'''  
 
''M Decat, P De Ryck, L Desmet, F Piessens, W Joosen''  
 
''M Decat, P De Ryck, L Desmet, F Piessens, W Joosen''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''Automated vs. Manual Security:&nbsp;You Can't Filter The Stupid'''<br>  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Automated vs. Manual Security:&nbsp;You Can't Filter The Stupid'''<br>  
 
''David Byrne and Charles Henderson''  
 
''David Byrne and Charles Henderson''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''How to Render SSL&nbsp;Useless'''  
+
<br>
''Ivan Ristic''  
+
 
 +
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''How to Render SSL&nbsp;Useless'''  
 +
''Ivan Ristic<br>''  
  
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:55-12:30  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 11:55-12:30  
 
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" |  
 
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" |  
'''Enterprise security patterns for&nbsp;RESTful Web Services'''  
+
[[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Enterprise security patterns for&nbsp;RESTful Web Services'''  
  
 
''Francois Lascelles''<br>  
 
''Francois Lascelles''<br>  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''Web Frameworks and How They Kill Traditional Security Scanning'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Web Frameworks and How They Kill Traditional Security Scanning'''  
 
''Christian Hang''  
 
''Christian Hang''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''The State of SSL&nbsp;in the World'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''The State of SSL&nbsp;in the World'''  
''Michael Boman''  
+
''Michael Boman<br>''  
  
 
|-
 
|-
Line 190: Line 193:
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 13:45-14:20  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 13:45-14:20  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | '''Securing Web Applications with ESAPI'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Securing Web Applications with ESAPI'''  
 
''Ken Sipe''  
 
''Ken Sipe''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''Beyond the Same Origin Policy'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''Beyond the Same Origin Policy'''  
''Jasvir Nagra and Mike Samuel''  
+
''Jasvir Nagra and Mike Samuel<br>''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''SymFileFuzzer - a New File Fuzzer Tool'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''SymFileFuzzer - a New File Fuzzer Tool'''  
 
''Komal Randive''  
 
''Komal Randive''  
  
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:30-15:05  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 14:30-15:05  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | '''Security Toolbox for .NET&nbsp;Development and Testing'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''Security Toolbox for .NET&nbsp;Development and Testing'''  
 
''Johan Lindfors and Dag König''  
 
''Johan Lindfors and Dag König''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''Cross-Site Location Jacking (XSLJ) (not really)'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''Cross-Site Location Jacking (XSLJ) (not really)'''  
 
''David Lindsay and Eduardo Vela Nava''  
 
''David Lindsay and Eduardo Vela Nava''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''Owning Oracle:&nbsp;Sessions and Credentials'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''Owning Oracle:&nbsp;Sessions and Credentials'''  
 
''Wendel G. Henrique and Steve Ocepek''  
 
''Wendel G. Henrique and Steve Ocepek''  
  
Line 215: Line 218:
 
|-
 
|-
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:30-16:05  
 
| style="width: 10%; background: none repeat scroll 0% 0% rgb(123, 138, 189);" | 15:30-16:05  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | '''Value Objects a la Doman-Driven Security:&nbsp;A&nbsp;Design Mindset to Avoid SQL&nbsp;Injection and Cross-Site Scripting Vulnerabilities'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 133, 122);" | [[Image:OWASP AppSec Research 2010 Demo D.gif]] '''Value Objects a la Doman-Driven Security:&nbsp;A&nbsp;Design Mindset to Avoid SQL&nbsp;Injection and Cross-Site Scripting'''  
 
''Dan Bergh Johnsson''  
 
''Dan Bergh Johnsson''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | '''New Insights into Clickjacking'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(188, 165, 122);" | [[Image:OWASP AppSec Research 2010 Presentation P.gif]] '''New Insights into Clickjacking'''  
''Marco Balduzzi''  
+
''Marco Balduzzi<br><br>''  
  
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | '''Session Fixation - the Forgotten Vulnerability?'''  
+
| align="left" style="width: 30%; background: none repeat scroll 0% 0% rgb(153, 255, 153);" | [[Image:OWASP AppSec Research 2010 Research R.gif]] '''Session Fixation - the Forgotten Vulnerability?'''  
 
''Michael Schrank, Bastian Braun and Martin Johns''  
 
''Michael Schrank, Bastian Braun and Martin Johns''  
  
Line 228: Line 231:
 
| align="center" colspan="3" style="width: 90%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Panel Discussion: To Be Announced
 
| align="center" colspan="3" style="width: 90%; background: none repeat scroll 0% 0% rgb(242, 242, 242);" | Panel Discussion: To Be Announced
 
|}
 
|}
 +
 +
== DAY 1, TRACK 1  ==
 +
 +
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] BitFlip: Determine a Data's Signature Coverage from within the Application  ===
 +
 +
by Henrich Christopher Poehls, University of Passau - ISL
 +
 +
Despite applied cryptographic primitives applications are working on data that was not protected by them. We show by abstracting the message flow between the application and the underlying wire, that protection is applied to a different data model. Taking problems from real life, like XML wrapping attacks and digital signatures on XML, we show that establishing the right linkage between the security checked on lower levels and the application above is practically difficult. We propose a application controlled check, the BitFlip-test. By this simple test an application can test if the application's assumed protection of a data value was indeed provided by the digital signature applied to the message that contained the value.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Towards Building Secure Web Mashups  ===
 +
 +
by Maarten Decat, Philippe De Ryck, Lieven Desmet, Frank Piessens, and Wouter Joosen, Katholieke Universiteit Leuven
 +
 +
Web mashups combine components from multiple sources into a single, interactive application. This kind of setup typically requires both interaction between the components to achieve the necessary functionality, as well as component separation to achieve a secure execution. Unfortunately, the traditional web is not designed to easily fulfill both requirements, which can be seen in the restrictions imposed by traditional development techniques. This paper gives an overview of these traditional techniques and investigates new developments, specifically aimed at combining components in a secure manner. In addition, topics for further improvement are identified to ensure a wide adaptation of secure mashups.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Enterprise security patterns for RESTful Web services  ===
 +
 +
by Francois Lascelles, Layer 7 Technologies
 +
 +
This presentation discusses security mechanisms for RESTful Web services in cloud and enterprise deployments. Understand the relationship between REST principles and security for RESTful Web service. Learn about current practices involving SSL, HMAC authentication schemes, OAuth, SAML, and perimeter security patterns involving specialized infrastructure.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Securing Web Applications with ESAPI  ===
 +
 +
by Ken Sipe, Perficient
 +
 +
When it comes to cross cutting software concerns, we expect to have or build a common framework or utility to solve this problem. This concept is represented well in the Java world with the loj4j framework, which abstracts the concern of logging, where it logs and the management of logging. The one cross cutting software concern which seems for most applications to be piecemeal is that of security. Security concerns include certification generation, SSL, protection from SQL Injection, protection from XSS, user authorization and authentication. Each of these separate concerns tend to have there own standards and libraries and leaves it as an exercise for the development team to cobble together a solution which includes multiple needs.... until now... Enterprise Security API library from OWASP.
 +
 +
This session will look at a number of security concerns and how the ESAPI library provides a unified solution for security. This includes authorization, authentication of services, encoding, encrypting, and validation. This session will discuss a number of issues which can be solved through standardizing on the open source Enterprise Security API.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Security Toolbox for .NET Development and Testing  ===
 +
 +
by Johan Lindfors and Dag König, Microsoft
 +
 +
Being a developer on the Microsoft platform leveraging .NET doesn’t only involve keeping up with the continuous development of the underlying framework and technologies. It also means to be on top of the latest security threats and naturally the available mitigations and best practices to protect the customers and users of the applications and solutions being developed.
 +
 +
In this session we will demonstrate how you as a .NET developer can leverage existing tools and technologies to build safer applications. During the demonstrations you will get more familiar with the existing tools within Visual Studio but also be introduced and educated in more tools that will help you build a toolbox for secure development and security testing.
 +
 +
But one must also remember that tools will never replace knowledge and hence we will also show you how you can regularly get updated with the latest information from Microsoft on security including how to leverage SDL – Security Development Lifecycle, within your own projects.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Value Objects a la Domain-Driven Security: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting  ===
 +
 +
by Dan Bergh Johnsson, Omegapoint
 +
 +
SQL Injection and Cross-Site Scripting have been topping the OWASP Top Ten for the last years. It must be a top priority for the community to evolve designs and mindsets that help the programmers to avoid these traps in their day-to-day work, where they have so much else but security that calls for their attention. The ambition of this presentation is to show design and coding practices that are well established in other fields of software development and put them to use to avoid just-mentioned traps. We also show some small refactorings that can be immediately applied to an existing codebase to make significant improvements to its security. Attendants of the session should be able to go back to work Monday morning and finish an improvement in this style before Monday lunch. We take inspiration from Domain Driven Design (DDD), which is characterized by its focus on what the software intend to represent. In particular, we make heavy use of the Value Object design pattern, where strict typing help us enforce that the incoming data is truthful to the restrictions of the domain. We start out with Injection Flaws and use the canonical username SQL Injection attack (“’OR 1=1 --“) as an example. Realizing that mentioned string was not intended as a valid username we elaborate the model to reflect this. Further more we make this change explicit in the code by introducing the new type and class Username. This also gives a natural place to put validation code, which otherwise often is placed in utility classes where it is easily forgotten and seldom called. In fact, we can even design service methods to require a validated Username, thus using the strong typing to enforce validation in the calling client system tier. Making this re-design with associated code changes is performed as a demo, and en route we discuss other design options and their relative merits and drawbacks. Again using DDD we proceed to analyse XSS. In the same way we see that XSS is in the general case not an indata validation problem. An extended analysis proposes that it can be phrased as an output-encoding problem. Using a similar technique we model the target domain of web content as the new type HTMLString, and can thereby enforce conversion from ordinary strings to strings with the proper encoding. If you have multiple content channels, then each channel will All steps needed are shown in code, starting with a vulnerable application and through controlled refactoring steps ending up with a version without the vulnerability. In summary, we will take an established quality practice from another field of software development and use it to get security improvements. The main benefits are two: firstly, the method gently guides and reminds the programmers to include validation and encoding in an unobtrusive way. Secondly, the work can be performed in very small steps, where the first can be finished before lunch Monday after the conference.
 +
 +
== DAY 1, TRACK 2  ==
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] CsFire: browser‐enforced mitigation against CSRF  ===
 +
 +
by Lieven Desmet and Philippe De Ryck, Katholieke Universiteit Leuven
 +
 +
Cross-Site Request Forgery (CSRF) is a web application attack vector that can be leveraged by an attacker to force an unwitting user's browser to perform actions on a third party website, possibly reusing all cached authentication credentials of that user.
 +
 +
Currently, a whole range of techniques exist to mitigate CSRF, either by protecting the server application or by protecting the end-user. Unfortunately, the server-side protection mechanisms are not yet widely adopted, and the client-side solutions provide only limited protection or cannot deal with complex web 2.0 applications, which use techniques such as AJAX, mashups or single sign-on (SSO).
 +
 +
In this talk, we will presents three interesting results of our research: (1) an extensive, real‐world traffic analysis to gain more insights in cross‐domain web interactions, (2) requirements for client‐side mitigation against CSRF and an analysis of existing browser extensions and (3) CsFire, our newly developed FireFox extension to mitigate CSRF.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Automated vs. Manual Security: You can’t filter "The Stupid"  ===
 +
 +
by David Byrne and Charles Henderson, Trustwave
 +
 +
Everyone wants to stretch their security budget, and automated application security tools are an appealing choice for doing so. However, manual security testing isn’t going anywhere until the HAL application scanner comes online. This presentation will use often humorous, real-world examples to illustrate the relative strengths and weaknesses of automated solutions and manual techniques.
 +
 +
Automated tools certainly have some strengths (namely low incremental cost, detecting simple vulnerabilities, and performing highly repetitive tasks). In addition to preventing some attacks, WAFs also have advantages for some compliance frameworks. However, automated solutions are far from perfect. To begin with, there are entire classes of very important vulnerabilities that are theoretically impossible for automated software to detect (at least until HAL comes online). Examples include complex information leakage, race conditions, logic flaws, design flaws, subjective vulnerabilities such as CSRF, and multistage process attacks.
 +
 +
Beyond that, there are many vulnerabilities that are too complicated or obscure to practically detect with an automated tool. Automated tools are designed to cover common application designs and platforms. Applications using an unusual layout or components will not be thoroughly protected by automated tools. Realistically, only the most vanilla of web applications written on common, simple platforms will receive solid code coverage from an automated tool.
 +
 +
On the other hand, manual testing is far more versatile. An experienced penetration tester can identify complicated vulnerabilities in the same way that an attacker does. Specific, real-world examples of vulnerabilities only recognizable by humans will be provided. The diversity of vulnerabilities shown will clearly demonstrate that all applications have the potential for significant vulnerabilities not detectable by automated tools.
 +
 +
Manual source code reviews present even more benefits by identifying vulnerabilities that require access to source code. Examples include “hidden” or unused application components, SQL injection with no evidence in the response, exotic injection attacks (e.g. mainframe session attacks), vulnerabilities in back-end systems, and intentional backdoors. Many organizations assume that this type of vulnerability is not a large threat, but source code can be obtained by disgruntled developers, by internal attackers when the repository isn’t properly secured, by exploiting platform bugs or path directory traversal attacks, and by external attackers using a Trojan horse or similar technique.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Web Frameworks and how they kill traditional security scanning  ===
 +
 +
by Christian Hang and Lars Andren, Armorize Technologies
 +
 +
Modern web application frameworks present a challenge to static analysis technologies due to how they influence application behavior in ways not obvious from the source code. This prevents efficient security scanning and can cause up to 80% of total potential issues to remain undetected due to the incorrect framework handling. After explaining the underlying problems, we demonstrate in a real world walk through using code analysis to scan actual application code. By extending static analysis with new framework specific components, even applications using complex frameworks like Struts and Smarty can be inspected automatically and code coverage of security analysis can be greatly enhanced.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Beyond the same-origin policy  ===
 +
 +
by Jasvir Nagra and Mike Samuel, Google Inc
 +
 +
The same-origin policy has governed interaction between client-side code and user data since Netscape 2.0, but new development techniques are rendering it obsolete. Traditionally, a website consisted of server-side code written by trusted, in-house developers&nbsp;; and a minimum of client-side code written by the same in-house devs. The same-origin policy worked because it didn't matter whether code ran server-side or client-side&nbsp;; the user was interacting with code produced by the same organization. But today, complex applications are being written almost entirely in client-side code requiring developers to specialize and share code across organizational boundaries.
 +
 +
This talk will explain how the same-origin policy is breaking down, give examples of attacks, discuss the properties that any alternative must have, introduce a number of alternative models being examined by the Secure EcmaScript committee and other standards bodies, demonstrate how they do or don't thwart these attacks, and discuss how secure interactive documents could open up new markets for web developers. We assume a basic familiarity with web application protocols&nbsp;: HTTP, HTML, JavaScript, CSS&nbsp;; and common classes of attacks&nbsp;: XSS, XSRF, Phishing.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Cross-site Location Jacking (XSLJ) (not really)  ===
 +
 +
David Lindsay, Cigital Inc, and Eduardo Vela Nava sla.ckers.org
 +
 +
Redirects are commonly used on many websites and are an integral part of many web frameworks. However, subtle and not so subtle issues can lead to security holes and privacy issues. In this presentation, we will discuss several high and low level issues related to redirects and demonstrate how the issues can be exploited.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] New insights into clickjacking  ===
 +
 +
Marco Balduzzi, Eurecom
 +
 +
Over the past year, clickjacking received extensive media coverage. News portals and security forums have been overloaded by posts claiming clickjacking to be the upcoming security threat. In a clickjacking attack, a malicious page is constructed (or a benign page is hijacked) to trick the user into performing unintended clicks that are advantageous for the attacker, such as propagating a web worm, stealing confidential information or abusing of the user session. In this talk, we formally define the problem and introduce our novel solution for automated detection of clickjacking attacks. We present the details of the system architecture and its implementation, and we evaluate the results we obtained from the analysis of over a million unique Internet pages. We conclude by discussing the clickjacking phenomenon and its future implications.
 +
 +
== DAY 1, TRACK 3  ==
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] Deconstructing ColdFusion  ===
 +
 +
Chris Eng, Veracode
 +
 +
This presentation is a technical survey of ColdFusion security, which will be of interest mostly to code auditors and penetration testers. We’ll cover the basics of ColdFusion markup, control flow, functions, and components and demonstrate how to identify common web application vulnerabilities at the source code level. We’ll also delve into ColdFusion J2EE internals, describing some of the unexpected properties we’ve observed while decompiling ColdFusion applications for static analysis.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Presentation word.gif]] How To Render SSL Useless  ===
 +
 +
Ivan Ristic, Feisty Duc
 +
 +
SSL is the technology that secures the Internet, but it is effective only when deployed properly. While the SSL protocol itself is very robust and easy to use, the same cannot be said for the usability of the complete ecosystem, which includes server configuration, certificates and application implementation details. In fact, SSL deployment is generally plagued with traps at every step of the way. As a result, too many web sites use insecure deployment practices that render SSL completely useless. In this talk I will present a list of top ten (or thereabout) deployment mistakes, based on my work on the SSL Labs assessment platform (https://www.ssllabs.com).
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] The state of SSL in the world  ===
 +
 +
Michael Boman, Omegapoint
 +
 +
What is the status of SSL deployments in Fortune 500 companies and the top 10'000 websites (according to Alexa)? While developing a tool that was needed to perform the test-case OWASP-CM-001 (Testing for SSL-TLS) it was noticed that some sites had very good SSL-configuration, sometimes unexpectedly, and some sites has very poor security configuration, even when you could expect the site to have good security standard. Does the organization behind the site has any bearing on how good the security standard the site has in regards to HTTPS-support and configuration? The talk will highlight the findings and the tools and process of obtaining the underlying data, while also trying to answer the questions: - How many of the Fortune 500 and Top 10'000 websites offer an HTTPS-enabled browser experience to their visitors? - How is the HTTPS-server configured in regards to SSL-protocols offered, key exchange and key lengths (bit-size)? - Are there any correlation between company size, industry or popularity and the HTTPS-enabled browsing experience and the HTTPS-configuration?
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] SymFileFuzzer - a new file fuzzer tool  ===
 +
 +
Komal Randive, Symantec
 +
 +
Here is a tool SymFileFuzzer designed and developed to address the same problem with ease. SymFileFuzzer understands the file formats and then user can specify the fields in the file to be fuzzed. SymFileFuzzer acts on a sample file of the required format and generates multiple fuzzed file copies from this sample file. SymFileFuzzer also has the support to add more custom file formats to be able to fuzz them, especially .dat formats. In comparison with the existing file fuzzers and frameworks this fuzzer has simple language for adding new formats, many more modes of fuzzing and attack oriented fuzzing. Following are the highlights of this fuzzer
 +
 +
*Support to understand the file formats and fuzz specific fields with specified/random data
 +
*Understands the correlation between different fields and manipulates them in accordance with the fuzzed content.
 +
*Can generate valid fuzzed files even based on the partial format understanding. Only the portions of file format which are understood by the user can be used to generate valid fuzzed files.
 +
*Understands the custom formats for file types and also for the configuration files(e.g key value pair format or .dat formats)
 +
*Tool is designed to be easily extended for any new file formats
 +
*Fuzz strings are read from a dictionary file. Users can add application specific input string to this dictionary for testing.
 +
*It’s a unix shell based tool which can be easily scripted.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Demo word.gif]] Owning Oracle: Sessions and Credentials  ===
 +
 +
Wendel G. Henrique and Steve Ocepek, Trustwave
 +
 +
In a world of free, ever-present encryption libraries, many penetration testers still find a lot of great stuff on the wire. Database traffic is a common favorite, and with good reason: when the data includes PAN, Track, and CVV, it makes you stop and wonder why this stuff isn’t encrypted across the board. However, despite this weakness, we still need someone to issue queries before we see the data. Or maybe not… after all, it’s just plaintext.
 +
 +
Wendel G. Henrique and Steve Ocepek of Trustwave’s SpiderLabs division offer a closer look at the world’s most popular relational database: Oracle. Through a combination of downgrade attacks and session take-over exploits, this talk introduces a unique approach to database account hijacking. Using a new tool, thicknet, the team will demonstrate how deadly injection and downgrade attacks can be to database security.
 +
 +
The Oracle TNS/Net8 protocol was studied extensively during presentation for this talk. Very little public knowledge of this protocol exists today, and much of the data gained is, as far as we know, new to Oracle outsiders.
 +
 +
Also, during the presentation we will be offering to attendants:
 +
 +
*Knowledge about man-in-the-middle and downgrade attacks, especially the area of data injection.
 +
*A better understanding of the network protocol used by Oracle.
 +
*The ability to audit databases against this type of attack vector.
 +
*Ideas for how to prevent this type of attack, and an understanding of the value of encryption and digital signature technologies.
 +
*Understanding of methodologies used to reverse-engineer undocumented protocols.
 +
 +
=== [[Image:OWASP AppSec Research 2010 Research word.gif]] Session Fixation - the Forgotten Vulnerability?  ===
 +
 +
Michael Schrank and Bastian Braun, University of Passau, and Martin Johns, SAP Research
 +
 +
The term 'Session Fixation vulnerability' subsumes issues in Web applications that under certain circumstances enable the adversary to perform a session hijacking attack through ontrolling the victim's session identier value. We explore this vulnerability pattern. First, we give an analysis of the root causes and document existing attack vectors. Then we take steps to assess the current attack surface of Session Fixation. Finally, we present a transparent server-side method for mitigating vulnerabilities.
  
 
==== June 24  ====
 
==== June 24  ====
Line 399: Line 556:
 
*Full-time students*: €225
 
*Full-time students*: €225
  
<nowiki>*</nowiki> We need some kind of proof of your full-time student status. Either ask your local OWASP chapter leader to vouch for you by email to [email protected], or email Kate a scanned image of your student ID (please compress the file size&nbsp;:).
+
<nowiki>*</nowiki> We need some kind of proof of your full-time student status. Either ask your local OWASP chapter leader to vouch for you by email to [email protected], or email Kate a scanned image of your student ID (please compress the file size&nbsp;:).  
  
 
== Training Fee (June 21-22)  ==
 
== Training Fee (June 21-22)  ==

Revision as of 10:37, 11 April 2010


Welcome

Invitation

Ladies and Gentlemen,

In June 21-24, 2010 let's all meet in beautiful Stockholm, Sweden. The OWASP chapters in Sweden, Norway, and Denmark hereby invite you to OWASP AppSec Research 2010.

If you have any questions, please email the conference chair: john.wilander at owasp.org

Stockholm old town small.jpg

Sponsors

Diamond sponsor:
AppSec Research 2010 Microsoft diamond sponsor.jpg

Gold sponsors:
Cybercom logo.png Portwise logo.png
Fortify logo AppSec Research 2010.png Omegapoint logo.png

Silver sponsors (3 taken, 5 open):
Mnemonic logo.png AppSec Research 2010 sponsor Nixu logo.jpg AppSec Research 2010 Google 20k sponsor.jpg

Lunch sponsors (1 taken, 1 open):
IIS logo.png

Coffee break sponsors (1 taken, 3 open):
MyNethouse logo.png

Media sponsors:
AppSec Research 2010 Help Net Security sponsor.jpg

For full sponsoring program see the Sponsoring tab above.

"AppSec Research".equals("AppSec Europe")

This conference was formerly known as OWASP AppSec Europe. We have added 'Research' to highlight that we invite both industry and academia. All the regular AppSec Europe visitors and topics are welcome along with contributions from universities and research institutes.

This will be the European conference for anyone interested in or working with application security. Co-host is the Department of Computer and Systems Science at Stockholm University, offering a great venue in the fabulous Aula Magna.

Countdown Challenges -- Free Tickets to Win!

There will be a challenge posted on the conference wiki page the 21st every month up until the event. The winner will get free entrance to the conference. What are you waiting for? Go to the Challenges tab and have fun!

Organizing Committee

• John Wilander, chapter leader Sweden (chair)
• Mattias Bergling (vice chair)
• Alan Davidson, Stockholm University/Royal Institute of Technology (co-host)
• Ulf Munkedal, chapter leader Denmark
• Kåre Presttun, chapter leader Norway
• Stefan Pettersson (sponsoring coordinator)
• Carl-Johan Bostorp (schedule and event coordinator)
• Martin Holst Swende (coffee/lunch/dinner)
• Predrag Mitrovic, OWASP Sweden Board
• Kate Hartmann, OWASP
• Sebastien Deleersnyder, OWASP Board

Welcome to Stockholm this year!
Regards, John Wilander

June 21-22 (Training)

Training Registration is now OPEN

Application security training is given the first two days, June 21-22. The price is €990 (~$1.350) for a two-day course. Take the chance to learn from the best!

Course 1: Threat Modeling and Architecture Review (two days)

AppSec Research 2010 Pravir Chandra.jpg

Pravir Chandra, Fortify Software

Abstract: Threat Modeling and Architecture Review are the cornerstones of a preventative approach to Application Security. By combining these topics into single comprehensive course attendees can get a complete understanding of how to understand the threat an application faces and how the application will handle those potential threats. This enables the risk to be accurately assessed and appropriate changes or mitigating controls recommended.

Trainer Bio: Pravir Chandra is Director of Strategic Services at Fortify where he works with clients to build and optimize software security assurance programs. Pravir is widely recognized in the industry for his expertise in software security and code analysis, and also for his ability to apply technical knowledge strategically from a business perspective. His book, Network Security with OpenSSL is a popular reference on protecting software applications through cryptography and secure communications. His varied special project experience includes creating and leading the Open Software Assurance Maturity Model (OpenSAMM) project

--> Register here

Course 2: Introduction to Malware Analysis (two days)

AppSec Research 2010 Jason Geffner.jpg

Jason Geffner, Next Generation Security Software (NGS), and Scott Lambert, Microsoft

Abstract: Security researchers are facing a growing problem in the complexity of malicious executables. While dynamic black-box automation tools exist to discover what malware will do on a given execution, it is often important for an analyst to know the full capabilities of a given malware sample. What port does it listen on? What password does it expect for backdoor access? What files will it write to? What will it do tomorrow that it didn't do today? This class will focus on teaching attendees the steps required to understand the functionality of given malware samples. This is a hands-on course. Attendees will work on real-world malware through a series of lab exercises designed to build their expertise in understanding the analysis process.

Learning Objectives:

  • An understanding of how to use reverse engineering tools
  • An understanding of low-level code and data flow
  • PE File format
  • x86 Assembly language
  • API functions often used by malware
  • Anti-analysis tricks and how to defeat them
  • Exploits and Shellcode
  • A methodology for analyzing malware with and without the use of specialized tools

Trainer Bio: Jason Geffner joined Next Generation Security Software Ltd. in June of 2007 as a Principal Security Consultant. Jason focuses on performing security reviews of source code and designs, reverse engineering software protection methods and DRM protection methods, deobfuscating and analyzing malware, penetration testing web applications and network infrastructures, and developing automated security analysis tools.

--> Register here

Course 3: Building Secure Ajax and Web 2.0 Applications (two days)

AppSec Research 2010 Dave Wichers.jpg

Dave Wichers, Aspect Security

Abstract: Students gain hands-on testing experience with freely available web application security test tools to find and diagnose flaws and learn how to identify them in their own projects. Because finding flaws is worthless without effective communication, the course also covers the process of creating and communicating software security flaws effectively. In addition, Aspect’s engineers are leaders in the AppSec Community and will offer the students an amazing perspective.

From the course outline:
CSS Attacks, Browser Add On Attacks, RSS / Data Feed Attacks, Microsoft Active X, Adobe Flash/Flex/AIR, Silverlight, Java FX, Ajax Mashups, Same Origin Policy, JavaScript, Web 2.0 CSRF Attacks, XHR JSON Forgery, Best Practice: Check HTTP Headers, Best Practice: Unique ID For XHR, JSON and XML Based XSS, How to use OWASP AntiSamy, Blended Threats, Dealing with Ajax Toolkits, Best Practice: Fuzzing ...

Trainer Bio: Dave Wichers is a member of the OWASP Board and a coauthor, along with Jeff Williams, of all previous versions of the OWASP Top Ten. Dave is also the Chief Operating Officer of Aspect Security, a company that specializes in application security services. Mr. Wichers brings over twenty years of experience in the information security field. Prior to cofounding Aspect, he ran the Application Security Services Group at a large data center company, Exodus Communications. His current work involves helping customers, from small e-commerce sites to Fortune 500 corporations and the U.S. Government, secure their applications by providing application security design, architecture, and SDLC support services: including code review, application penetration testing, security policy development, security consulting services, and developer training.

--> Register here

Course 4: Assessing and Exploiting Web Apps with Samurai-WTF (two days)

AppSec Research 2010 Justin Searle.jpg

Justin Searle, InGuardians

Abstract: This course will focus on using open source tools to perform web application assessments. The course will take attendees through the process of application assessment using the open source tools included in the Samurai Web Testing Framework Live CD (Samurai-WTF). Day one will take students through the steps and open source tools used to assess applications for vulnerabilities. Day two will focus on the exploitation of web app vulnerabilities, spending half the day on server side attacks and the other half of the day on client side attacks. The latest tools and techniques will be use throughout the course, including several tools developed by the trainers themselves.

Trainer Bio: Justin Searle, a Senior Security Analyst with InGuardians, specializes in web application, network, and embedded penetration testing. Justin has presented at top security conferences including DEFCON, ToorCon, ShmooCon, and SANS. Justin has an MBA in International Technology and is CISSP and SANS GIAC-certified in incident handling and hacker techniques (GCIH) and intrusion analysis (GCIA). Justin is one of the founders and lead developers of Samurai-WTF.

--> Register here

Course 5: Securing Web Services (two days)

AppSec Research 2010 Jason Li.jpg

Jason Li, Aspect Security

Abstract: Aspect Security offers a one or two day course titled Securing Web Services designed to focus on the most important messages regarding the development and of secure web services. The objective for this course is to ensure that developers understand the real risks associated with Service Oriented Architectures, what standard are available to help, and how to use the standards. The course includes a combination of lecture and demonstration designed to provide detailed guidance regarding the implementation of specific security principles and functions.

Trainer Bio: Jason Li is a Senior Application Security Engineer for Aspect Security where he performs application security assessments and architecture reviews, as well as application security training, to a wide variety of financial and government customers. Jason is an active OWASP leader, contributing to several OWASP projects and serving on the OWASP Global Projects Committee. He holds a Post-Masters certificate in Computer Science and concentration in Information Security from Johns Hopkins University and a Masters degree in Computer Science from Cornell University.

--> Register here

June 23

OWASP AppSec Research 2010 Research R.gif = Research paper OWASP AppSec Research 2010 Demo D.gif = Demo OWASP AppSec Research 2010 Presentation P.gif = Presentation

Conference Day 1 - June 23, 2010

Track 1 Track 2 Track 3
08:00-08:50 Registration and Coffee
08:50-09:00 Welcome to OWASP AppSec Research 2010 Conference (John Wilander & Dave Wichers)
09:00-10:00 Keynote: Cross-Domain Theft and the Future of Browser Security

Chris Evans, Information Security Engineer, and Ian Fette, Product Manager for Chrome Security, Google

10:10-10:45 OWASP AppSec Research 2010 Research R.gif BitFlip: Determine a Data's Signature Coverage from within the Application

Henrich Christopher Poehls

OWASP AppSec Research 2010 Presentation P.gif CsFire: Browser Enforced Mitigation Against CSRF

Lieven Desmet and Philippe De Ryck

OWASP AppSec Research 2010 Presentation P.gif Deconstructing ColdFusion

Chris Eng

10:45-11:10 Break - Expo CTF Kick-Off
11:10-11:45 OWASP AppSec Research 2010 Research R.gif Towards Building Secure Web Mashups

M Decat, P De Ryck, L Desmet, F Piessens, W Joosen

OWASP AppSec Research 2010 Presentation P.gif Automated vs. Manual Security: You Can't Filter The Stupid

David Byrne and Charles Henderson


OWASP AppSec Research 2010 Presentation P.gif How to Render SSL Useless

Ivan Ristic

11:55-12:30

OWASP AppSec Research 2010 Presentation P.gif Enterprise security patterns for RESTful Web Services

Francois Lascelles

OWASP AppSec Research 2010 Presentation P.gif Web Frameworks and How They Kill Traditional Security Scanning

Christian Hang

OWASP AppSec Research 2010 Demo D.gif The State of SSL in the World

Michael Boman

12:30-13:45 Lunch - Expo - CTF
13:45-14:20 OWASP AppSec Research 2010 Presentation P.gif Securing Web Applications with ESAPI

Ken Sipe

OWASP AppSec Research 2010 Presentation P.gif Beyond the Same Origin Policy

Jasvir Nagra and Mike Samuel

OWASP AppSec Research 2010 Demo D.gif SymFileFuzzer - a New File Fuzzer Tool

Komal Randive

14:30-15:05 OWASP AppSec Research 2010 Demo D.gif Security Toolbox for .NET Development and Testing

Johan Lindfors and Dag König

OWASP AppSec Research 2010 Demo D.gif Cross-Site Location Jacking (XSLJ) (not really)

David Lindsay and Eduardo Vela Nava

OWASP AppSec Research 2010 Demo D.gif Owning Oracle: Sessions and Credentials

Wendel G. Henrique and Steve Ocepek

15:05-15:30 Break - Expo - CTF
15:30-16:05 OWASP AppSec Research 2010 Demo D.gif Value Objects a la Doman-Driven Security: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting

Dan Bergh Johnsson

OWASP AppSec Research 2010 Presentation P.gif New Insights into Clickjacking

Marco Balduzzi

OWASP AppSec Research 2010 Research R.gif Session Fixation - the Forgotten Vulnerability?

Michael Schrank, Bastian Braun and Martin Johns

16:15-17:00 Panel Discussion: To Be Announced

DAY 1, TRACK 1

OWASP AppSec Research 2010 Research word.gif BitFlip: Determine a Data's Signature Coverage from within the Application

by Henrich Christopher Poehls, University of Passau - ISL

Despite applied cryptographic primitives applications are working on data that was not protected by them. We show by abstracting the message flow between the application and the underlying wire, that protection is applied to a different data model. Taking problems from real life, like XML wrapping attacks and digital signatures on XML, we show that establishing the right linkage between the security checked on lower levels and the application above is practically difficult. We propose a application controlled check, the BitFlip-test. By this simple test an application can test if the application's assumed protection of a data value was indeed provided by the digital signature applied to the message that contained the value.

OWASP AppSec Research 2010 Research word.gif Towards Building Secure Web Mashups

by Maarten Decat, Philippe De Ryck, Lieven Desmet, Frank Piessens, and Wouter Joosen, Katholieke Universiteit Leuven

Web mashups combine components from multiple sources into a single, interactive application. This kind of setup typically requires both interaction between the components to achieve the necessary functionality, as well as component separation to achieve a secure execution. Unfortunately, the traditional web is not designed to easily fulfill both requirements, which can be seen in the restrictions imposed by traditional development techniques. This paper gives an overview of these traditional techniques and investigates new developments, specifically aimed at combining components in a secure manner. In addition, topics for further improvement are identified to ensure a wide adaptation of secure mashups.

OWASP AppSec Research 2010 Presentation word.gif Enterprise security patterns for RESTful Web services

by Francois Lascelles, Layer 7 Technologies

This presentation discusses security mechanisms for RESTful Web services in cloud and enterprise deployments. Understand the relationship between REST principles and security for RESTful Web service. Learn about current practices involving SSL, HMAC authentication schemes, OAuth, SAML, and perimeter security patterns involving specialized infrastructure.

OWASP AppSec Research 2010 Presentation word.gif Securing Web Applications with ESAPI

by Ken Sipe, Perficient

When it comes to cross cutting software concerns, we expect to have or build a common framework or utility to solve this problem. This concept is represented well in the Java world with the loj4j framework, which abstracts the concern of logging, where it logs and the management of logging. The one cross cutting software concern which seems for most applications to be piecemeal is that of security. Security concerns include certification generation, SSL, protection from SQL Injection, protection from XSS, user authorization and authentication. Each of these separate concerns tend to have there own standards and libraries and leaves it as an exercise for the development team to cobble together a solution which includes multiple needs.... until now... Enterprise Security API library from OWASP.

This session will look at a number of security concerns and how the ESAPI library provides a unified solution for security. This includes authorization, authentication of services, encoding, encrypting, and validation. This session will discuss a number of issues which can be solved through standardizing on the open source Enterprise Security API.

OWASP AppSec Research 2010 Demo word.gif Security Toolbox for .NET Development and Testing

by Johan Lindfors and Dag König, Microsoft

Being a developer on the Microsoft platform leveraging .NET doesn’t only involve keeping up with the continuous development of the underlying framework and technologies. It also means to be on top of the latest security threats and naturally the available mitigations and best practices to protect the customers and users of the applications and solutions being developed.

In this session we will demonstrate how you as a .NET developer can leverage existing tools and technologies to build safer applications. During the demonstrations you will get more familiar with the existing tools within Visual Studio but also be introduced and educated in more tools that will help you build a toolbox for secure development and security testing.

But one must also remember that tools will never replace knowledge and hence we will also show you how you can regularly get updated with the latest information from Microsoft on security including how to leverage SDL – Security Development Lifecycle, within your own projects.

OWASP AppSec Research 2010 Demo word.gif Value Objects a la Domain-Driven Security: A Design Mindset to Avoid SQL Injection and Cross-Site Scripting

by Dan Bergh Johnsson, Omegapoint

SQL Injection and Cross-Site Scripting have been topping the OWASP Top Ten for the last years. It must be a top priority for the community to evolve designs and mindsets that help the programmers to avoid these traps in their day-to-day work, where they have so much else but security that calls for their attention. The ambition of this presentation is to show design and coding practices that are well established in other fields of software development and put them to use to avoid just-mentioned traps. We also show some small refactorings that can be immediately applied to an existing codebase to make significant improvements to its security. Attendants of the session should be able to go back to work Monday morning and finish an improvement in this style before Monday lunch. We take inspiration from Domain Driven Design (DDD), which is characterized by its focus on what the software intend to represent. In particular, we make heavy use of the Value Object design pattern, where strict typing help us enforce that the incoming data is truthful to the restrictions of the domain. We start out with Injection Flaws and use the canonical username SQL Injection attack (“’OR 1=1 --“) as an example. Realizing that mentioned string was not intended as a valid username we elaborate the model to reflect this. Further more we make this change explicit in the code by introducing the new type and class Username. This also gives a natural place to put validation code, which otherwise often is placed in utility classes where it is easily forgotten and seldom called. In fact, we can even design service methods to require a validated Username, thus using the strong typing to enforce validation in the calling client system tier. Making this re-design with associated code changes is performed as a demo, and en route we discuss other design options and their relative merits and drawbacks. Again using DDD we proceed to analyse XSS. In the same way we see that XSS is in the general case not an indata validation problem. An extended analysis proposes that it can be phrased as an output-encoding problem. Using a similar technique we model the target domain of web content as the new type HTMLString, and can thereby enforce conversion from ordinary strings to strings with the proper encoding. If you have multiple content channels, then each channel will All steps needed are shown in code, starting with a vulnerable application and through controlled refactoring steps ending up with a version without the vulnerability. In summary, we will take an established quality practice from another field of software development and use it to get security improvements. The main benefits are two: firstly, the method gently guides and reminds the programmers to include validation and encoding in an unobtrusive way. Secondly, the work can be performed in very small steps, where the first can be finished before lunch Monday after the conference.

DAY 1, TRACK 2

OWASP AppSec Research 2010 Presentation word.gif CsFire: browser‐enforced mitigation against CSRF

by Lieven Desmet and Philippe De Ryck, Katholieke Universiteit Leuven

Cross-Site Request Forgery (CSRF) is a web application attack vector that can be leveraged by an attacker to force an unwitting user's browser to perform actions on a third party website, possibly reusing all cached authentication credentials of that user.

Currently, a whole range of techniques exist to mitigate CSRF, either by protecting the server application or by protecting the end-user. Unfortunately, the server-side protection mechanisms are not yet widely adopted, and the client-side solutions provide only limited protection or cannot deal with complex web 2.0 applications, which use techniques such as AJAX, mashups or single sign-on (SSO).

In this talk, we will presents three interesting results of our research: (1) an extensive, real‐world traffic analysis to gain more insights in cross‐domain web interactions, (2) requirements for client‐side mitigation against CSRF and an analysis of existing browser extensions and (3) CsFire, our newly developed FireFox extension to mitigate CSRF.

OWASP AppSec Research 2010 Presentation word.gif Automated vs. Manual Security: You can’t filter "The Stupid"

by David Byrne and Charles Henderson, Trustwave

Everyone wants to stretch their security budget, and automated application security tools are an appealing choice for doing so. However, manual security testing isn’t going anywhere until the HAL application scanner comes online. This presentation will use often humorous, real-world examples to illustrate the relative strengths and weaknesses of automated solutions and manual techniques.

Automated tools certainly have some strengths (namely low incremental cost, detecting simple vulnerabilities, and performing highly repetitive tasks). In addition to preventing some attacks, WAFs also have advantages for some compliance frameworks. However, automated solutions are far from perfect. To begin with, there are entire classes of very important vulnerabilities that are theoretically impossible for automated software to detect (at least until HAL comes online). Examples include complex information leakage, race conditions, logic flaws, design flaws, subjective vulnerabilities such as CSRF, and multistage process attacks.

Beyond that, there are many vulnerabilities that are too complicated or obscure to practically detect with an automated tool. Automated tools are designed to cover common application designs and platforms. Applications using an unusual layout or components will not be thoroughly protected by automated tools. Realistically, only the most vanilla of web applications written on common, simple platforms will receive solid code coverage from an automated tool.

On the other hand, manual testing is far more versatile. An experienced penetration tester can identify complicated vulnerabilities in the same way that an attacker does. Specific, real-world examples of vulnerabilities only recognizable by humans will be provided. The diversity of vulnerabilities shown will clearly demonstrate that all applications have the potential for significant vulnerabilities not detectable by automated tools.

Manual source code reviews present even more benefits by identifying vulnerabilities that require access to source code. Examples include “hidden” or unused application components, SQL injection with no evidence in the response, exotic injection attacks (e.g. mainframe session attacks), vulnerabilities in back-end systems, and intentional backdoors. Many organizations assume that this type of vulnerability is not a large threat, but source code can be obtained by disgruntled developers, by internal attackers when the repository isn’t properly secured, by exploiting platform bugs or path directory traversal attacks, and by external attackers using a Trojan horse or similar technique.

OWASP AppSec Research 2010 Presentation word.gif Web Frameworks and how they kill traditional security scanning

by Christian Hang and Lars Andren, Armorize Technologies

Modern web application frameworks present a challenge to static analysis technologies due to how they influence application behavior in ways not obvious from the source code. This prevents efficient security scanning and can cause up to 80% of total potential issues to remain undetected due to the incorrect framework handling. After explaining the underlying problems, we demonstrate in a real world walk through using code analysis to scan actual application code. By extending static analysis with new framework specific components, even applications using complex frameworks like Struts and Smarty can be inspected automatically and code coverage of security analysis can be greatly enhanced.

OWASP AppSec Research 2010 Presentation word.gif Beyond the same-origin policy

by Jasvir Nagra and Mike Samuel, Google Inc

The same-origin policy has governed interaction between client-side code and user data since Netscape 2.0, but new development techniques are rendering it obsolete. Traditionally, a website consisted of server-side code written by trusted, in-house developers ; and a minimum of client-side code written by the same in-house devs. The same-origin policy worked because it didn't matter whether code ran server-side or client-side ; the user was interacting with code produced by the same organization. But today, complex applications are being written almost entirely in client-side code requiring developers to specialize and share code across organizational boundaries.

This talk will explain how the same-origin policy is breaking down, give examples of attacks, discuss the properties that any alternative must have, introduce a number of alternative models being examined by the Secure EcmaScript committee and other standards bodies, demonstrate how they do or don't thwart these attacks, and discuss how secure interactive documents could open up new markets for web developers. We assume a basic familiarity with web application protocols : HTTP, HTML, JavaScript, CSS ; and common classes of attacks : XSS, XSRF, Phishing.

OWASP AppSec Research 2010 Demo word.gif Cross-site Location Jacking (XSLJ) (not really)

David Lindsay, Cigital Inc, and Eduardo Vela Nava sla.ckers.org

Redirects are commonly used on many websites and are an integral part of many web frameworks. However, subtle and not so subtle issues can lead to security holes and privacy issues. In this presentation, we will discuss several high and low level issues related to redirects and demonstrate how the issues can be exploited.

OWASP AppSec Research 2010 Presentation word.gif New insights into clickjacking

Marco Balduzzi, Eurecom

Over the past year, clickjacking received extensive media coverage. News portals and security forums have been overloaded by posts claiming clickjacking to be the upcoming security threat. In a clickjacking attack, a malicious page is constructed (or a benign page is hijacked) to trick the user into performing unintended clicks that are advantageous for the attacker, such as propagating a web worm, stealing confidential information or abusing of the user session. In this talk, we formally define the problem and introduce our novel solution for automated detection of clickjacking attacks. We present the details of the system architecture and its implementation, and we evaluate the results we obtained from the analysis of over a million unique Internet pages. We conclude by discussing the clickjacking phenomenon and its future implications.

DAY 1, TRACK 3

OWASP AppSec Research 2010 Presentation word.gif Deconstructing ColdFusion

Chris Eng, Veracode

This presentation is a technical survey of ColdFusion security, which will be of interest mostly to code auditors and penetration testers. We’ll cover the basics of ColdFusion markup, control flow, functions, and components and demonstrate how to identify common web application vulnerabilities at the source code level. We’ll also delve into ColdFusion J2EE internals, describing some of the unexpected properties we’ve observed while decompiling ColdFusion applications for static analysis.

OWASP AppSec Research 2010 Presentation word.gif How To Render SSL Useless

Ivan Ristic, Feisty Duc

SSL is the technology that secures the Internet, but it is effective only when deployed properly. While the SSL protocol itself is very robust and easy to use, the same cannot be said for the usability of the complete ecosystem, which includes server configuration, certificates and application implementation details. In fact, SSL deployment is generally plagued with traps at every step of the way. As a result, too many web sites use insecure deployment practices that render SSL completely useless. In this talk I will present a list of top ten (or thereabout) deployment mistakes, based on my work on the SSL Labs assessment platform (https://www.ssllabs.com).

OWASP AppSec Research 2010 Demo word.gif The state of SSL in the world

Michael Boman, Omegapoint

What is the status of SSL deployments in Fortune 500 companies and the top 10'000 websites (according to Alexa)? While developing a tool that was needed to perform the test-case OWASP-CM-001 (Testing for SSL-TLS) it was noticed that some sites had very good SSL-configuration, sometimes unexpectedly, and some sites has very poor security configuration, even when you could expect the site to have good security standard. Does the organization behind the site has any bearing on how good the security standard the site has in regards to HTTPS-support and configuration? The talk will highlight the findings and the tools and process of obtaining the underlying data, while also trying to answer the questions: - How many of the Fortune 500 and Top 10'000 websites offer an HTTPS-enabled browser experience to their visitors? - How is the HTTPS-server configured in regards to SSL-protocols offered, key exchange and key lengths (bit-size)? - Are there any correlation between company size, industry or popularity and the HTTPS-enabled browsing experience and the HTTPS-configuration?

OWASP AppSec Research 2010 Demo word.gif SymFileFuzzer - a new file fuzzer tool

Komal Randive, Symantec

Here is a tool SymFileFuzzer designed and developed to address the same problem with ease. SymFileFuzzer understands the file formats and then user can specify the fields in the file to be fuzzed. SymFileFuzzer acts on a sample file of the required format and generates multiple fuzzed file copies from this sample file. SymFileFuzzer also has the support to add more custom file formats to be able to fuzz them, especially .dat formats. In comparison with the existing file fuzzers and frameworks this fuzzer has simple language for adding new formats, many more modes of fuzzing and attack oriented fuzzing. Following are the highlights of this fuzzer

  • Support to understand the file formats and fuzz specific fields with specified/random data
  • Understands the correlation between different fields and manipulates them in accordance with the fuzzed content.
  • Can generate valid fuzzed files even based on the partial format understanding. Only the portions of file format which are understood by the user can be used to generate valid fuzzed files.
  • Understands the custom formats for file types and also for the configuration files(e.g key value pair format or .dat formats)
  • Tool is designed to be easily extended for any new file formats
  • Fuzz strings are read from a dictionary file. Users can add application specific input string to this dictionary for testing.
  • It’s a unix shell based tool which can be easily scripted.

OWASP AppSec Research 2010 Demo word.gif Owning Oracle: Sessions and Credentials

Wendel G. Henrique and Steve Ocepek, Trustwave

In a world of free, ever-present encryption libraries, many penetration testers still find a lot of great stuff on the wire. Database traffic is a common favorite, and with good reason: when the data includes PAN, Track, and CVV, it makes you stop and wonder why this stuff isn’t encrypted across the board. However, despite this weakness, we still need someone to issue queries before we see the data. Or maybe not… after all, it’s just plaintext.

Wendel G. Henrique and Steve Ocepek of Trustwave’s SpiderLabs division offer a closer look at the world’s most popular relational database: Oracle. Through a combination of downgrade attacks and session take-over exploits, this talk introduces a unique approach to database account hijacking. Using a new tool, thicknet, the team will demonstrate how deadly injection and downgrade attacks can be to database security.

The Oracle TNS/Net8 protocol was studied extensively during presentation for this talk. Very little public knowledge of this protocol exists today, and much of the data gained is, as far as we know, new to Oracle outsiders.

Also, during the presentation we will be offering to attendants:

  • Knowledge about man-in-the-middle and downgrade attacks, especially the area of data injection.
  • A better understanding of the network protocol used by Oracle.
  • The ability to audit databases against this type of attack vector.
  • Ideas for how to prevent this type of attack, and an understanding of the value of encryption and digital signature technologies.
  • Understanding of methodologies used to reverse-engineer undocumented protocols.

OWASP AppSec Research 2010 Research word.gif Session Fixation - the Forgotten Vulnerability?

Michael Schrank and Bastian Braun, University of Passau, and Martin Johns, SAP Research

The term 'Session Fixation vulnerability' subsumes issues in Web applications that under certain circumstances enable the adversary to perform a session hijacking attack through ontrolling the victim's session identier value. We explore this vulnerability pattern. First, we give an analysis of the root causes and document existing attack vectors. Then we take steps to assess the current attack surface of Session Fixation. Finally, we present a transparent server-side method for mitigating vulnerabilities.

June 24

Conference Day 2 - June 24, 2010
Track 1 Track 2 Track 3
09:00-10:00 Keynote: The Security Development Lifecycle -- The Creation and Evolution of a Security Development Process
Steve Lipner, Senior Director of Security Engineering Strategy, Microsoft Corporation
10:10-10:45

Building Security In Maturity Model: A Review of Successful Software Security Programs in Europe

Gabriele Giuseppini and Terri Randolph

Promon TestSuite -- Client Based Penetration Testing Tool

Folker den Braber and Tom Lysemose Hansen

A Taint Mode for Python via a Library
2.0

Juan José Conti and Alejandro Russo

10:45-11:10 Break - Expo - CTF
11:10-11:45

Microsoft's Security Development Lifecycle for Agile Development

Nick Coblentz

Detecting and Protecting You Users from 100% of all Malware -- How?

Bradley Anstis and Ellynora Nicoll

OPA: Language Support for a Sane, Safe and Secure Web

David Rajchenbach-Teller and François-Régis Sinot

11:55-12:30

Secure Application Development for the Enterprise: Practical, Real-World Tips

Michael Craigue

Responsibility for the Harm and Risk of Software Security Flaws

Cassio Goldschmidt

Secure the Clones: Static Enforcement of Policies for Secure Object Copying

Thomas Jensen and David Pichardie

12:30-13:45 Lunch - Expo - CTF
13:45-14:20

Product Security Management in Agile Product Management

Antti Vähä-Sipilä

Hacking by Numbers

Tom Brennan

Safe Wrappers and Sane Policies for Self Protecting JavaScript

Jonas Magazinius, Phu H. Phung and David Sands

14:30-15:05

OWASP Top 10 2010

Dave Wichers

Application Security Scoreboard in the Sky

Chris Eng

On the Privacy of File Sharing Services

Nick Nikiforakis, Francesco Gadaleta, Yves Younan, and Wouter Joosen

15:05-15:30 Break - Expo - CTF
15:30-16:00 CTF Price Ceremony, Announcement of OWASP AppSec EU 2011, Closing Notes

Invited Talks

"Cross-Domain Theft and the Future of Browser Security"

Appsec research 2010 invited talk 1.jpg

Chris Evans
Troublemaker, Information Security Engineer, and Tech Lead at Google inc.
Also the sole author of vsftpd.

Ian Fette
Product Manager for Chrome Security and Google's Anti-Malware initiative

Abstract
The web browser, and associated machinery, is on the front line of attacks. We will first look at design-level problems with the traditional browser in terms of monolithic architecture and fundamental problems with the same-origin policy. We will then look at the types of solution that are starting to appear in browsers such as Google Chrome and Internet Explorer. We will look at other important browser-based defenses such as Safe Browsing. We will detail what a future browser might look like that has a much more secure design, but is still usable on the wide variety of web sites that people use daily.

"The Security Development Lifecycle -- The Creation and Evolution of a Security Development Process"

Appsec research 2010 invited talk 2.jpg

Steve Lipner
Senior Director of Security Engineering Strategy, Trustworthy Computing Security, Microsoft Corporation.
Co-author of "The Security Development Lifecycle", Microsoft Press (book cover above).

Abstract
This keynote will review the evolution of the Security Development Lifecycle (SDL) from its origins in the Microsoft “security pushes” of 2002-3 through its current status and application in 2010. It will emphasize the aspects of change and change management as the SDL and its user community have matured and grown and will conclude with a summary of some recent changes and additions to the SDL. Specific topics to be addressed include:

  • Motivations for introducing both the SDL and its predecessor processes.
  • Considerations in selling the process to management and sustaining a mandate over a prolonged period.
  • Scaling the SDL to an organization with tens of thousands of engineers.
  • Managing change.
  • The role of automation in the SDL.
  • Adaptation of the SDL to agile development processes.
  • Thoughts for organizations that are considering implementing the SDL.

The presentation will cover technical aspects of the SDL including a brief review of requirements and tools, and results.

Speaker Bio
Steven B. Lipner is senior director of Security Engineering Strategy at Microsoft Corp where he is responsible for programs that provide improved product security for Microsoft customers. Lipner leads Microsoft’s Security Development Lifecycle (SDL) team and is responsible for the definition of Microsoft’s SDL and for programs to make the SDL available to organizations beyond Microsoft. Lipner is also responsible for Microsoft’s corporate strategies related to government security evaluation of Microsoft products. Lipner joined Microsoft in 1999 and was initially responsible for the Microsoft Security Response Center. In the aftermath of the major computer “worm” incidents of 2001, Lipner and his team formulated and led programs that helped customers respond to the immediate challenges posed by software vulnerabilities and Internet worms. Lipner and his team also devised the strategy of “security pushes” that, as part of the Trustworthy Computing initiative, enabled Microsoft to make rapid improvements in the security of its software products and to change the corporate development culture to emphasize product security. The SDL is the product of these improvements, and is widely viewed as the industry’s leading secure software development process.

Before joining Microsoft, Lipner worked for a variety of software vendors and government contractors as a researcher, consultant, development manager and general manager in IT security. Many of the concepts whose development he led form the basis for today’s approaches to building secure systems. Some examples of these contributions include the application of virtual machine monitors (VMMs) as an approach to isolating security domains, and mathematical models for multilevel security.

Lipner is coauthor with Michael Howard of The Security Development Lifecycle (Microsoft Press, 2006) and is named as inventor on twelve U.S. patents and two pending applications in the field of computer and network security. He has authored numerous professional papers and conference presentations, and served on several National Research Council committees. He served two terms – a total of more than ten years – on the United States Information Security and Privacy Advisory Board and its predecessor. Lipner holds S.B. and S.M. degrees in Civil Engineering from the Massachusetts Institute of Technology and attended the Harvard Business School’s Program for Management Development.

Registration

Registration is now OPEN

Click Here To Register

Note: To save on processing expenses, all fees paid for the OWASP conference are non-refundable. OWASP can accommodate transfers of registrations from one person to another, if such an adjustment becomes necessary.

Stay Informed ... and Tell Others

Subscribe to the conference mailing list. This is the official information channel and you'll be the first to know about the program, invited speakers, opening of registration for training etc.

Add the event to your LinkedIn profle to tell all your business contacts that AppSec Research 2010 is the place to be.

Then get on the Twitter stream by using the tags #OWASP and #AppSecEU.

Conference Fees (June 23-24)

  • Regular registration: €350
  • OWASP individual member (not just chapter member): €300
  • Full-time students*: €225

* We need some kind of proof of your full-time student status. Either ask your local OWASP chapter leader to vouch for you by email to [email protected], or email Kate a scanned image of your student ID (please compress the file size :).

Training Fee (June 21-22)

  • Training fee is €990 for two days, see Training tab above

Travel & Hotels

Travel

Stockholm's foremost international airport is Arlanda (ARN). Clean and convenient speed trains will take you between Arlanda and Stockholm Central in 20 minutes. You can also fly to Stockholm Skavsta (NYO) or Stockholm Västerås (VST) where coaches take you to Stockholm Central in 1 h 20 min.

Accommodation

You can choose hotel/hostel freely in Stockholm but we provide three suggestions with pre-booked rooms. Before you book check with sites like hotels.com since they might have better prices for the very same hotels!

Stockholm map with hotels and public transportation.jpg

Subways and buses are convenient and safe and will take you right up to the venue (station/stop "Universitetet") from these three hotels:

Best Western Time Hotel
Why? Closest to the university, direct bus or subway to the conference
Best Western Time Hotel
Single room: 1395 SEK/€145/$195
Double room: 1575 SEK/€160/$220
Rooms pre-booked until May 6 under code "G#73641 OWASP"

Scandic Continental
Why? Right at the Central Station, convenient travel to and from airport, direct subway to the conference
Scandic Continental
Single room: 1590 SEK/€165/$220
Double room: 1690 SEK/€175/$235
Rooms pre-booked until early May under code "OWASP"

Fridhemsplan's Hostel
Why? Affordable stay in Stockholm's nicest hostel, direct bus to the conference
Fridhemsplan's Hostel
Rooms cost €35-€55 ($50-$80)
Booking via John Wilander ([email protected]). First-come-first-served with priority to students or people who have the need ;).

Venue

AppSec Research 2010 Aula Magna.jpg

Sponsoring

We are now welcoming sponsors for OWASP AppSec Research 2010. Take the opportunity to support next year's major appsec event in Europe! The full sponsoring program is available as pdfs:

Sponsoring program in English: File:OWASP Sponsorship AppSec Research 2010 (eng).pdf

Sponsoring program in Swedish: File:OWASP Sponsorship AppSec Research 2010 (swe).pdf

Part of the sponsoring program
Part of the sponsoring program

Challenges

Countdown Challenges -- Free Tickets to Win!

There will be a challenge posted on the conference wiki page the 21st every month up until the event. The winner will get free entrance to the conference. Be sure to sign up for the conference mailing list to get a monthly reminder.

AppSec Research Challenge X: Build an Enterprise Java Rootkit

The tenth challenge is here!

Jeff Williams, chairman of OWASP, gave a very interesting talk at last year's Black Hat US and OWASP AppSec US -- "Enterprise Java Rootkits -- Hardly Anyone Watches the Developers". Now it's time for you to write a rootkit yourself, exploring Jeff's techniques and more.

The Project to Fool
Your assignment is to be the evil developer who implements and hides a backdoor in a Java servlet. We've implemented a very simple login web application and exported the Eclipse project (zip here). We will use this project to evaluate your submissions. It's a simple servlet/jsp project that we deployed on Tomcat 6.0. It even contains an evil output of user credentials to a temp file (not yet hidden though) to get you started. Screenshot from the app and the project structure:


Appsec research 2010 challenge X eclipse project.jpg Appsec research 2010 challenge X login screen.jpg

Rules

  • You must explain what your changes do (we need to evaluate your rootkit!)
  • The original features + look and feel must be preserved
  • Your additions should preferably look like security features such as IP whitelisting, logging, anti-CSRF, frequency blocking etc.
  • You're only allowed to change the servlet (Login.java), and the gif image (appsec_research_challenge_X.gif)
  • You do not have to use the jsps
  • The original size of Login.java is 1,856 bytes and it mustn't grow to more than 4,000 bytes
  • The gif image mustn't grow in size and should look close enough to the original to fool the committee
  • Code should "look" readable, i e not minimized too heavily

How To Win
The organization committee will evaluate who has been able to hide the most evil stuff while complying to the rules. The more malicious functionality and the more clever disguise -- the more "points". All submissions must be posted as links or pasted code in this sla.ckers.org thread. Send an email to [email protected] when you post code or need attention. Deadline April 20.


Archive

Call for Papers and Proposals (closed)

AppSec Research 2010 2nd cfp.png


1. Publish or Perish. Peer-reviewed 12 page papers to be published in formal proceedings by Springer-Verlag (Lecture Notes in Computer Science, LNCS). Presentation slides and video takes will be posted on the OWASP wiki after the conference.
2. Demo or Die. A demo proposal should consist of a pdf with a 1 page abstract summarizing the matter proposed by the speaker(s) and 1 page containing demo screenshot(s). Demos will have ordinary speaker slots but the speakers are expected to run a demo during the talk (live coding counts as a demo), not just a slideshow. Presentation slides and video takes will be posted on the OWASP wiki after the conference.
3. Present or Repent. A presentation proposal should consist of a 2 page extended abstract representing the essential matter proposed by the speaker(s). Presentation slides and video takes will be posted on the OWASP wiki after the conference.

If you have any questions regarding submissions etc, please email [email protected].

Topics of Interest

We encourage the publication and presentation of new tools, new methods, empirical data, novel ideas, and lessons learned in the following areas:

•    Web application security
•    Security aspects of new/emerging web technologies/paradigms (mashups, web 2.0,  offline support, etc)
•    Security in web services, REST, and service oriented architectures
•    Security in cloud-based services
•    Security of frameworks (Struts, Spring, ASP.Net MVC etc)
•    New security features in platforms or languages
•    Next-generation browser security
•    Security for the mobile web
•    Secure application development (methods, processes etc)
•    Threat modeling of applications
•    Vulnerability analysis (code review, pentest, static analysis etc)
•    Countermeasures for application vulnerabilities
•    Metrics for application security
•    Application security awareness and education

Submission Deadline and Instructions

Update: Submission deadline for full-papers ("Publish or Perish") has been extended to March 7th 23:59 (Apia, Samoa time) due to numerous requests. Submit your paper to AppSec Research 2010 (EasyChair).

Full-paper submissions should be at most 12 pages long and must be in the Springer LNCS style for "Proceedings and Other Multiauthor Volumes". Templates for preparing papers in this style for LaTeX, Word, etc can be downloaded from: http://www.springer.com/computer/lncs?SGWID=0-164-7-72376-0. Full papers must be submitted in a form suitable for anonymous review: remove author names and affiliations from the title page, and avoid explicit self-referencing in the text.

Submission for "Demo or Die" and "Present or Repent" closed on February 7th.

Decision notification: April 7th

Program Committee (for review of full-papers)

• John Wilander, Omegapoint and Linköping University (chair)
• Alan Davidson, Stockholm University/Royal Institute of Technology (co-host)
• Lieven Desmet, Katholieke Universiteit Leuven
• Úlfar Erlingsson, Reykjavík University and Microsoft Research
• Martin Johns, University of Passau
• Christoph Kern, Google
• Engin Kirda, Institute Eurecom
• Ulf Lindqvist, SRI International
• Benjamin Livshits, Microsoft Research
• Sergio Maffeis, Imperial College London
• John Mitchell, Stanford University
• William Robertson, UC Berkeley
• Andrei Sabelfeld, Chalmers UT

Call for Training (closed)

(Info kept here for reference)
OWASP is currently soliciting training proposals for the OWASP AppSec Research 2010 Conference which will take place at Stockholm University in Sweden, on June 21st through June 24th 2010. There will be training courses on June 21st and 22nd followed by plenary sessions on the 23rd and 24th with three tracks per day.

We are seeking training proposals on the following topics (in no particular order):

  • Security in Web 2.0, Web Services/XML
  • Advanced penetration testing
  • Static analysis for security
  • Threat modeling of applications
  • Secure coding practices
  • Security in J2EE/.NET patterns and frameworks
  • Application security with ESAPI
  • OWASP tools in practice

We will look favourably on laboration-based/hands-on training.

Submission Deadline and Instructions

Submission deadline is Sunday February 7th 23:59 (Apia, Samoa time). To submit your training proposal please fill out the File:OWASP AppSec Research 2010 Call for Training.docx and email it to [email protected] with subject "AppSec Research 2010: Training proposal".

Upon acceptance you'll be requested to fill out the Training Instructor Agreement where you'll find details on revenue split etc. The agreement will be reworked but the previous one is here: File:Training Instructor Agreement.doc.

Upcoming List of Trainers on OWASP Wiki

As part of the OWASP Education Project, OWASP is starting an official list of trainers on the OWASP web site. This list (mentioning the trainer - course and contact details) will cover all trainers that performed training at OWASP conferences, together with their aggregated scores on the course feedback forms. Of course, this is opt-in. Please let us know if you are interested to participate in this program (tick the check-box on the application form).

AppSec Research Challenge 9: Crack 'Em Hashes (closed)

February's AppSec Research 2010 challenge is about breaking hashed passwords. It starts off easy with the old LM hash and ends with SHA256 and GOST3411.

Owasp appsec research 2010 hash challenge.jpg

How To Win
The first one to publish each broken password gets points according to the table below but at the same time helps the others since the password is the salt of the next hash. So you have to decide -- should you publish your cracked password and collect your points before the others or should you keep it a secret to get a head start cracking the next one? Deadline it March 21st.

To collect points for a password you must be the first one to publish that broken password on this sla.ckers.org thread. Please send an email to [email protected] at the same time so we can correct any misunderstandings. For instance we can happen to run into hash collisions, where someone finds another mixed alpha password of max 5 characters that concatenated with the right salt produces the same hash. In such a case we will publish the real password and give points to the one who found the collision.

The one with the most points on March 21st wins a free ticket to the conference!

Points to Earn

  • pwd1 (LM) => 1 point
  • pwd2 (MD2) => 3 points
  • pwd3 (MD4) => 5 points
  • pwd4 (MD5) => 9 points
  • pwd5 (RIPEMD160) => 15 points
  • pwd6 (SHA1) => 25 points
  • pwd7 (SHA256) => 50 points
  • pwd8 (GOST3411) => 100 points

The Hashes
Each password comprises of a-zA-Z (mixed alpha) and is max 5 characters long. With salt that means max 10 mixed alpha characters as input to the hash function. All hashes here are in hex format. The Java source code has all the details. The plus operator means string concatenation.

  • LM(pwd1) 0C04DACA901299DBAAD3B435B51404EE
  • MD2(pwd2 + pwd1) 16189F5462BF906E9D88CF6F152DE86F
  • MD4(pwd3 + pwd2) FA8F46A6D347087D6980C3FA77DD4DE9
  • MD5(pwd4 + pwd3) 425B33D6F60394C897B8413B5C185845
  • RIPEMD160(pwd5 + pwd4) 35F34671D30472D403937820DCABC1C78C837071
  • SHA1(pwd6 + pwd5) AE81A30510B2931921934218636B26A803330EB1
  • SHA256(pwd7 + pwd6) B2FF0269E927C6559804A37590A0688C45DF143F85CEE0E3F239F846B65C9644
  • GOST3411(pwd8 + pwd7) 16CC9F1FF65688E040F5ADA82A41A258FF948769CDA4C4A17D85228A6F358971

Example: Given that pwd1 is "Win" and pwd2 is "You", the hash 16189F5462BF906E9D88CF6F152DE86F is the result of MD2("YouWin"). Now pwd2 will be the salt when you crack pwd3.

The Source Code
The source code we've used to produce the hashes is available here zip. It's Java and all but the LM hash is done with Bouncy Castle 1.4.5.


AppSec Research Challenge 8: Construct an OWASP Polyglot (closed)

January's AppSec Research Challenge is to construct an OWASP polyglot, more specifically an OWASP logo that also can be run as JavaScript:

Show image: <img src="owasp_logo.gif">
Run script: <script src="owasp_logo.gif"></script>

Wikipedia says: "a polyglot is a computer program or script written in a valid form of multiple programming languages". This is about as cool as it gets :).

Rules

  • Make your polyglot out of the regular OWASP logo in the upper left corner of this wiki (circle with the wasp).
  • The file size must not grow.
  • Pixel colors in the gif must not differ more than 5 in red, green, or blue. Ex: If a pixel originally had rgb 100,100,100 then 104,95,96 is OK.
  • No malicious stuff of course
  • When your polyglot is run as JavaScript it should execute as many of the following features as possible, starting from the top:
  1. alert(all cookies belonging to the current domain);
  2. alert(the last keystrokes on the keyboard every ten keystrokes);
  3. alert(the current time in Stockholm, once every minute);
  4. A quine. The polyglot outputs its own source code on the HTML page.

How to get started

Jasvir Nagra gave a talk on these kind of polyglots and published a gif/JavaScript polyglot on his blog. A good starting point is his gif file. Jasvir has also written an extensive article on gif/perl polyglots which explains how to get code into the gif file. Check out his guide.

How to win

Submit your entries in this sla.ckers.org thread. Either the first complete polyglot or the most complete polyglot wins. We will most probably provide you with a gif checker that validates the color differences. Check the thread. 

AppSec Research Challenge 7: X-Mas Capture the Flag (closed)

AppSec Research 2010 Stocking.gif Merry Christmas everyone!AppSec Research 2010 Stocking.gif

It's the 21st and a new AppSec Research Challenge is posted.

Setting up the AppSec Research 2010 X-mas Challenge was a cooperative effort by the winner of AppSec Research Challenge 3, Mario Heiderich, and Martin Holst Swende. It is a multi-step challenge which involves finding a vulnerability in a web application and locating a hidden message. The winner gets free entrance to next year's conference. Start by subscribing to the conference mailing list. Then check the simple rules below and get going.

Rules:

  • Please do not perform any resource-intensive tests, as the machine is pretty low-end and can be DoS:ed without much effort.
  • The computer at the given IP address is the only system involved in this challenge, so please do not perform any tests of neighboring systems.
  • Otherwise, you are free to hack away!

Challenge-page: 66.249.7.26

Discussions, QnA and reports about how far you have made it is welcome at the official sla.ckers thread.

Good luck and happy holidays! (And don't forget the submission deadline for the conference -- February 7)


AppSec Research Challenge 6: Design the Conference Logo (closed)

Note: This challenge is re-opened. Submit by February 21st.

November's AppSec Research 2010 Challenge asks you to design the conference logotype. So far we have used this:

Appsec research 2010 logo prototype (small).png

... but would like something less "word processor-like".

How to win

  • The logo should be suitable for both large printing and small web banners
  • If you make a color logo, please submit a b/w version too
  • "OWASP AppSec Research 2010" should in some way be part of the logo :)

Copyright?
By submitting your logo you agree to share it according to Creative Commons Attributions and that we credit you in the conference brochure and on the conference wiki but not in all places where we use the logo (i e we will not credit you on banners, sponsoring program, powerpoint presentations etc).

How to submit
Email jpg + svg to john.wilander [at] owasp.org before Monday December 14th 23:59 UTC. The creator of the best logo wins a free ticket to the AppSec Research 2010 conference!

AppSec Research Challenge 5: Graphical Effects (closed)

The October OWASP AppSec Research 2010 challenge is over. The winner of a free entrance ticket to next year's AppSec conference in Stockholm is "sirdarckcat" with FireworksIsNotABrowser_v4 (although we like the slightly oversized v6 better).

The challenge was about writing the coolest graphical effect in a 2010 character script.

An Example

As an example, copy the script below and paste the script over the URL in the URL bar.

javascript:R=0; x1=.1; y1=.05; x2=.25; y2=.24; x3=1.6; y3=.24; x4=300; y4=200; x5=300; y5=200; DI=document.getElementsByTagName("img"); DIL=DI.length; function A(){for(i=0; i-DIL; i++){DIS=DI[ i ].style; DIS.position='absolute'; DIS.left=(Math.sin(R*x1+i*x2+x3)*x4+x5)+"px"; DIS.top=(Math.cos(R*y1+i*y2+y3)*y4+y5)+"px"}R++}setInterval('A()',5); void(0)

As a simple teaser we give these png letters for the script to play with.

AppSec Research 2010 O.pngAppSec Research 2010 W.pngAppSec Research 2010 A.pngAppSec Research 2010 S.pngAppSec Research 2010 P.png

Rules

  • The script should work in Firefox 3.5 (yeah, that means HTML5 and CSS3 :)
  • Any resource, linked document, script, or image defined on the AppSec Research 2010 wiki page may be loaded/accessed/used
  • No requests to any other location is allowed
  • No obfuscation is allowed
  • The script may only use ASCII
  • Max length of the script is 2010 characters
  • You have to give your effect an id and a version number (further explanation below)
  • Any form of malicious code is of course banned ;)

How to Compete

There's an official thread on sla.ckers were you share your code and thoughts (Worried someone will steal you code? Check the originality bullet below). You can enter as many effects as you like but each effect has to have an id and a version number, e.g. JohnWobbler_v1.3 for version 1.3 of John's Wobbler effect. Deadline is November 14th, 23:59 UTC.

Choosing the Winner

Since this is a creative challenge the OC will choose the winner based on the following:

  • Originality (tweaking someone's code is cool and encouraged but changing a few magic numbers or inverting a function won't make you the winner)
  • Coolness (yeah, you need to convince a few Scandinavian people + Seba and Kate that your script is the coolest)

Either the OC will choose a winner by ourselves or we choose the top effects and let you guys vote for the winner.

AppSec Research Challenge 4: Who's Who in Security? (closed)

September's AppSec Research 2010 Challenge was to identify a number of people that are, in one way or another, known in the security business, by their picture. There were thirteen photos in total, portraiting thirteen different individuals.

The winner of a free ticket to the OWASP AppSec Research conference in 2010 was Thomas Vollstädt who submitted the correct solution just one day after the challenge was posted.

The Solution

Owasp appsec research 2010 challenge 4 solution.png

The Names

Dinis Cruz, Gordon "Fyodor" Lyon, David Litchfield, Dave Aitel, Bruce Schneier, Dave Wichers, Gene Spafford, MafiaBoy, MySpace Samy, Tom Brennan, Halvar Flake, Alex Sotirov, Jeff Williams, Jennifer Granick, Kate Hartmann, Mudge, Lance Spitzner, Dan Kaminsky, Brian Chess, Joanna Rutkowska, Crispin Cowan, Michael Howard, Jay Beale, Ross Anderson, Dawn Song, Robert "rsnake" Hansen, and Solar Designer.

The Pictures

If you'd like to see the original pictures without the names, here's the link: [[1]]

AppSec Research Challenge 3: Non-Alphanumeric JavaScript (closed)

The August AppSec Research 2010 Challenge was to create a JavaScript alert("owasp") that pops up the word 'owasp', case-insensitive, without using any alphanumeric characters (0-9a-zA-Z). There was a tremendous activity and we want to thank everyone who participated. The size of the final result was almost a third of the first entry (see chart below). Want to check out the winning snippet by .mario? Enter the following in the Firebug console: ω=[[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}][Ś+Ó+Ŕ+Ṫ],ω()[Á+Ĺ+É+Ŕ+Ṫ](Ó+ω()[Ḃ+Ṫ+Ó+Á]('Á«)'))

It is based on a few different ideas. First of all, a variable assignment on the form

[a,b,c,,e]="abcde" // a="a", c="c",e="e"

Which is performed on the string "truefalse[object Object]"

[Ṫ,Ŕ,,É,,Á,Ĺ,Ś,,,Ó,Ḃ]=!''+[!{}]+{}] // right-hand side is "truefalse[object Object]"

Also, the following construction obtains the window.sort-function, which leaks the window-object when called without arguments :

ω=[]["sort"] //ω is now window.sort

Therefore, calling ω()["alert"] invokes window.alert. To generate the string "owasp", the string "wasp" can be obtained by calling btoa on the characters "Á«)".

This was really a great team effort, and I think a lot of us learned some new tricks. The final winner was .mario. Congratulations!

Appsec research 2010 challenge 3 chart.jpg

JavaScript Without Alphanumeric Characters?

It is possible to write valid javascript completely without alphannumeric characters (0-9a-zA-Z). To produce a number, you can instead use for example an empty string, '', interpret it as a boolean with a bang: !'' -- which leads to the boolean object true. true, interpreted as a numeric value, equals one. Thus,

$ = +!''; // $ === 1

$++;$++; // $ === 3

In a similar fashion, strings can be created from strings embedded in the language. The boolean object true can be converted to string by concatenation, and then accessed by numeric index to, for example, produce the letter 'e' :

â = (!''+'')[$] // â[$] === "true"[3] === e

Previous Similar Contest

These two techniques are behind a previous contest at the forum "sla.ckers.org", where the contest was to create alert(1) with as few non-alphanumeric characters as possible. Currently, the code actually being executed was:

([],"sort")()["alert"](1) // since ([],"sort")() leaks window object in FF, ==> window["alert"](1) is called, which is another form of window.alert(1)

The winner, or at least current leading entry is 84 bytes long, and looks like this:

(Å='',[Į=!(ĩ=!Å+Å)+{}][Į[Š=ĩ[++Å]+ĩ[Å-Å],Č=Å-~Å]+Į[Č+Č]+Š])()[Į[Å]+Į[Å+Å]+ĩ[Č]+Š](Å)

The Challenge

August's challenge was to, in a similar fashion, create an alert("owasp"), case-insensitive, not using any alphanumeric characters. The shortest working code snippet submitted by September 18th 23:59:59 UTC won a free ticket. By "working" we meant JavaScript that executes in Firefox/Firebug, not depending on any Firebug DOM variables for execution.

Submissions were made as comments to the challenge 3 blogpost on Owasp Sweden. Check it out.

AppSec Research Challenge 2: OWASP Crossword Puzzle (closed)

July's crossword challenge is over. Many permutations arrived in our inbox but it was tricky to get it completely right. Congratulations to Johannes Dahse and Johan Nilsson who in the end were allowed to join forces to be able to find the correct solution. They win a 50 % conference ticket discount each.

You find the solution below.

Appsec research 2010 challenge 2 solution.gif

AppSec Research Challenge 1: Input Validation and Regular Expressions (closed)

This challenge is over. The winner was Partik Nordlén. To see the solution(s), please visit the appsec_eu_2010 mailing list archive.

Some people, when confronted with a problem, think “I know, I'll use regular expressions.” Now they have two problems.
        --Jamie Zawinski, in comp.emacs.xemacs

The 21st of each month up until the conference in June 2010 we'll have a countdown challenge posted here. The winner each month will get a free entrance ticket worth about €300/$400. Be sure to sign up for the conference mailing list to get a monthly reminder.

The Challenge

A community is hosted on a very large domain, yahoogle.com. The users of that community all have profiles, where they are allowed to use basic HTML for customization, as well as JavaScript files hosted on the domain.

All the code for the profile pages are filtered on the server side, and whenever a piece of code containing "<script..." is encountered, the following regular expression is used to validate that the script loaded is hosted on a subdomain of yahoogle.com:

.*(<script){1}([^>]+)src=('http:\/\/[a-zA-Z]+.yahoogle.com\/scripts\/[0-9A-Za-z]+\.js').*\/>

Capture group 3 is then also checked against a whitelist of allowed scripts on that domain. The whitelist consists of "http://secure.yahoogle.com" and "http://scripts.yahoogle.com".

Your task is to formulate a snippet of HTML that goes correctly through the filter and the whitelist, but loads the script "http://insecure.com/evil.js" instead. Also, rework the regular expression to defend against your "attack".

Email your solution to Martin Holst Swende <[email protected]>. The first correct answer wins a free ticket to the conference. The free ticket is personal and the judgement of the organizing committee can not be overruled :).