AppSec Europe 2014

We all know JS crypto is flawed, right? Over the years, security community has pointed out its multiple fundamental problems. Several arguments were made and "JavaScript cryptography is bound to fail" became a mantra. Of course, despite all this JS crypto WAS used all over the place. Theory met practice - it was about time to dig into this!

In recent months, we tested various high-profile, in the wild crypto libraries, applications and systems. We saw code from home-grown cryptography to full-blown TLS or OpenPGP implementations. Hilarious bugs were spotted, protections were bypassed and systems were pwned. But was it really that different from what we all had already seen in OpenSSL, BouncyCastle or GnuPGP? Can we actually fix all those bugs? Does it mean that Javascript cryptography can be, pardon us saying, secure like any other?

Come and listen. During the talk vulns will be shown, authorities - questioned, myths - debunked, and browsers cursed upon. You'll see the full picture - from XSS, to man-in-the-middle, to PRNGs and timing side-channels, even snippets in C. No stone will be left unturned, nothing will be taken for granted. You'll be left with an updated, solid and heavily opinionated view of JavaScript cryptography.

What is this all about?

The OWASP Security Shepherd project has been designed and implemented with the aim of fostering and improving security awareness among a varied skill­set demographic.This project enables users to learn or to improve upon existing manual penetration testing skills. This is accomplished through lesson and challenge techniques. A lesson provides a user with a lot of help in completing that module, where a challenge puts what the user learned in the lesson to use.

Security Shepherd covers the OWASP Top Ten web app risks and has recently been injected with totally new content to cover the OWASP Top Ten Mobile risks as well. Using these risks as a challenge test bed, common security vulnerabilities can be explored and their impact on a system understood. Many of these levels include insufficient mitigations and protections to these risks, such as blacklist filters, atrocious encoding schemes, barbaric security mechanisms and poor security configuration. The modules have been crafted to provide not only a challenge for a security novice, but security professionals as well.

Over the last year the OWASP Security Shepherd has proven itself to be a resilient platform in which CTF (Capture the Flag) events can be deployed upon. Examples include

1. 
   The OWASP Global CTF 2013
   
   


2. 
   IRISScon 2013 Cyber Security Challenge
   
   


3. 
   The OWASP EU Tour 2013 Online CTF
   
   


4. 
   Source Conference CTF
   
   


5. 
   The OWASP LATAM 2013 Tour Online CTF
   
   


6. 
   The OWASP Ireland AppSec 2012 CTF
   
   

One of the biggest concerns that organisers of CTF competitions have is that their system or scoreboard may be compromised. There are few open source projects that offer a secure CTF platform to utilise. With the Shepherd platform been subject to the playful prods and less playful assaults from five continents, it is a candidate to fill this gap. The OWASP Security Shepherd is in the process of been forked to provide the OWASP Shepherd CTF Platform. 

Teachers of Application Security in higher education institutions and universities are presented with some unique challenges, especially when compared to other scientific or even computer science fields. This is mainly because students have to learn how to design, implement and protect applications against both known and unknown attacks. Moreover, the so far established stereotypes present the potential intruders as being ingenious and able to penetrate almost every system.

The OWASP Hackademic Challenges Project introduces the "attacker's perspective" in higher education by implementing realistic scenarios with known vulnerabilities in a safe, controllable environment. Students can attempt to discover and exploit these vulnerabilities in order to learn important concepts of information security through the attacker's perspective.

Its main difference from other projects that implement vulnerable applications for educational purposes, is that it is has been created mainly for use in a classroom environment, while most other solutions take a more self-learning approach. The OWASP Hackademic Challenges are not just another set of vulnerable applications but a complete teaching environment. In this manner, students can be organized in classes with different set of challenges per class. A sophisticated grading system allows the assessment of students according to their effort and performance and not just the ability to solve the challenge, while several forms of cheating can also be detected.

The OWASP Hackademic Challenges are currently being used by more than a dozen universities around the world and are also part of the "Hacking Lab" and "OWASP University Challenge". In addition, we have received contributions to the project by several researchers, including the New Jersey Institute of Technology.

The OWASP Hackademic Challenges simulate real-world scenarios that application security consultants and penetration testers encounter during their day-to-day engagements, combined with the academic requirements of a related module. These exercises can be used to complement the respective theoretical lectures. Statistical analysis of the feedback we received from students through questionnaires, shows that the students embraced this approach and have benefited significantly from going through these exercises. In practice, the OWASP Hackademic Challenges help students become more enthusiastic about application security by gaining a realistic, hands-on experience on some real-world vulnerabilities.

In this presentation we will give an overview of the Hackademic Challenges and analyze its scientific background. In addition, we will present new features introduced to the interface that was developed during the Google Summer of Code 2013 which include a plugin API. Moreover, as the project is still under development, we expect a bunch of new features to be ready by the conference dates.

We will introduce the new concept of training modules, a significant addition whose aim is to integrate entire teaching modules. A training module refers to a bundle of reading material and challenges with specific scoring rules. This allows the users/professors to manage complete logical entities and allows for better modularity of the courses. Also, in our experience there is a significant number of students who once they finish a security course, they wish to write challenges and improve the course in general. This concept will allow them, and anyone wishing to contribute course material, to provide entire logical modules in a bundle. Also, this method allows for easier integration of other useful features which are being developed, such as gamification.

Our goal is to create an educational ecosystem around Hackademic that includes teachers, students and professionals who contribute and consume teaching material and realistic challenges in an open way.

Finally, we will introduce an open id integration module. This showcases a good security practice and allows the users to login with many popular open-id providers, simplifying the registration process.

A demo of the new Hackademic portal and challenges will also be delivered, emphasizing on how it can be used in a real classroom and giving the chance to attendees to get their hands on it. 

Many, many conferences nowadays come with "HTML5 is insecure" or "Hacking with HTML5" talks. This has lead to a general perception that HTML5 itself (whatever the term actually stands for) is insecure and, thus, should be avoided for security reasons. This is highly unfortunate, as the current generation of new Web APIs expose a level of security sophistication, which is unparalleled in the Web's history. In fact, new browser features such as CORS or PostMessage allow, for the first time, to securely realize usecases which, up to now, required the programmers to resort to insecure programming practices. 

In this talk, we will systematically explore security relevant HTML5 APIs. To do so, we discuss their respective security architecture and, more importantly, show how they compare to currently established techniques which were designed to realize similar use cases. 

Plainly speaking you can consider this talk as a "information security deathmatch - HTML5 vs. its alternative" (spoiler: HTML5 wins). 

More specifically, the talk will cover: 

# Client-side cross-domain communication: 

- CORS (HTML5) vs. JSONP and/or crossdomain.xml 

# Client-side persistence 

- LocalStorage (HTML5) vs. Cookie-hacks 

# In-browser communication 

- PostMessage (HTML5) vs. 
-- hash-identifier passing and/or 
-- window.name setting and/or 
-- domain relaxation 

# ClickJacking protection 

- X-Frames-Options (HTML5) vs. JavaScript framebusters 

# Bonus track: The browser's new security capabilities 

A quick overview of new browser features that can be used to secure Web sites: 

- Content Security Policies 
- Sandboxed iFrames 
- Strict-transport Security 

The session's content is based on the experiences and lessons learned of a international academic research project on modern Web security (WebSand, http://websand.eu) of which the speaker is the technical lead. All given details will be backed with empirical data (when applicable). Furthermore, all discussed technologies can be accompanied with proof-of-concept code or practical demonstrations (if time permits). 

Among application security stakeholders, Chief Information Security Officers (CISOs),are responsible for application security from governance, compliance and risk perspectives. The recently released OWASP CISO Survey provides tactical intelligence about security risks and best practices to help CISOs manage application security programs according to their own roles, responsibilities, perspectives and needs.

The Payment Card Industry Data Security Standard (PCI DSS) applies to whether cardholder data is stored, processed or transmitted. This presentation will examine the best practices in development of bespoke or custom written applications to be used within the cardholder data environment of the Payment Card Industry Data Security Standard (PCI DSS) to ensure the applications meet the compliance requirements of the standard. 

The objective of the talk is to inform those who are developing applications of the PCI DSS requirements, review the testing procedures that an auditor would use to examine compliance with the requirements and highlight the evidence the auditor will be expecting to collect to prove the requirements are being met continually. The purpose is to help them develop applications securely to the requirements. 

The presentation starts with an explanation of the applicability of the PCI DSS and how organisations may not be aware that they need to comply with the requirements, as they may not be directly involved with payment card transactions. Often, payment card details can be captured on expense tracking systems, corporate card management and other systems. Anywhere the PAN is captured, stored, processed or transmitted, even when not directly involved in a payment transaction, the PCI DSS still applies. For web applications such as shopping carts, although the checkout may redirect to a 3rd party, the application performing the redirect needs to be secure to prevent the redirection mechanism being manipulated to point to a malicious 3rd party site. 

Version 3 of the PCI DSS standard mandates a number of key best practices to ensure applications used provide the minimal level of protection of cardholder data during processing, storing and transmission of cardholder data. 

The key practices that will be covered are:- 
• Secure software development lifecycle practices that ensure the inclusion of security during the requirements definition, design, analysis, and testing phases of software development. 
• Requiring developers to understand how cardholder data is handled in memory, and how modern malware will scrape memory to retrieve sensitive data. 
• The use of separate development, testing and production environments; including separation of duties for developers, testers and production administrators. 
• The need to remove test account credentials and test data from application before it is released to the production environment. 
• Prohibition of the use of ‘live’ data for testing or development purposes. 
• The use of change control mechanisms to ensure all changes to system components are reviewed and authorised. 
• Software developers are trained in secure coding techniques and develop applications on secure coding guidelines. 
• The testing of applications to ensure they do not suffer from known vulnerabilities. 
• Public facing web applications are protected against known attacks. 

Each of these key practices will be examined from the point of view of a PCI Qualified Security Assessor. The author, who is a QSA, will look at how industry standards, such as those developed by OWASP, can be used by developers, testers and managers as part of the process of implementing a secure development lifecycle and used as evidence in meeting the PCI DSS requirements. 

The authors view on the key practices will be given, including interpretation of the requirements and how a QSA could expect to see them implemented to meet the testing requirements of the PCI DSS. 

The result should be that developers will understand when the PCI DSS could apply to applications they are developing and the best practices they will need to follow to ensure those application meet the requirements of the PCI DSS. This will enable those merchants and service providers using the applications in their operations to achieve compliance.