Sessions at Open Source Bridge 2011 about Security with notes

Tuesday 21st June 2011

• DNSSEC @ Mozilla

  by Shyam Mani

  The session will discuss the following topics :

  *Basics*
  Introduction to DNSSEC
  Why DNSSEC is needed
  New RR records – DNSKEY, DS, NSEC and RRSIG
  Keys
  Relationship between the new RR records and keys aka Chain of Trust[demo]

  *Implementation*
  Things to consider before you implement
  Setup at Mozilla, before and after
  Commands
  Config changes
  Steps to switch
  Verification [demo]
  Possible issues to be aware of

  *Errors*
  Mistakes I made, and you shouldn't

  *The Future*
  Where we stand with DNSSEC today
  Possible issues that delay DNSSEC implementation
  Data from Mozilla (before and after DNSSEC)
  Possible changes to Firefox/Other Software

  • DNS
  • dnssec
  • Internet
  • Mozilla
  • Security

  At 1:30pm to 2:15pm, Tuesday 21st June

  Coverage note

Wednesday 22nd June 2011

• Preventing Runtime Errors at Compile Time

  by David Lazar, Michael Ernst and Werner M. Dietl

  Are you tired of null pointer exceptions, unintended side effects, SQL injections, concurrency errors, mistaken equality tests, and other run-time errors that appear during testing or in the field? A pluggable type system can guarantee the absence of these errors, and many more real, important bugs.

  Are you a software architect who wants to be able to quickly and easily implement custom checks that prevent more errors at compile time? You need a framework that supports you in creating a formally correct code checker.

  This presentation is aimed at both audiences. A pluggable type system can give a compile-time guarantee of important properties. We will explain what it is, how to use it, and even how to create your own. You can create a simple pluggable type-checker in 2 minutes, and you can enhance it thereafter.

  The demo uses the Checker Framework, which enables you to create pluggable type systems for Java. It takes advantage of features planned by Oracle for Java 8, but your code remains backward-compatible. The pluggable type-checker can be run as part of javac or via an Eclipse plug-in, and integration with build tools such as Ant and Maven is provided. The tools are "freely available":http://types.cs.washington.edu/checker-framework/.

  The Checker Framework provides 12 pluggable type systems that are ready to use, including nullness, immutability, and locking checkers. The presentation will first develop a simple declarative type checker that checks the consistency of method signature strings. The presentation will then discuss the design and usage of more advanced checkers.

  The Checker Framework has found hundreds of bugs in over 3 million lines of open source code, including from Oracle, Google, Apache, etc. Overall, we found that the type checkers were easy to write, easy for novices to productively use, and effective in finding real bugs and verifying program properties, even for widely tested and used open source projects. It is easy to improve the quality of your Java code, and you can start using the Checker Framework today!

  • All Languages
  • Design
  • Documentation
  • Java
  • Security

  At 10:00am to 11:45am, Wednesday 22nd June

  Coverage note

Thursday 23rd June 2011

• Cookies are Bad for You: Improving Security on the Web

  by Jesse Hallett

  The release of "Firesheep":http://codebutler.com/firesheep last year and "the presentation by Reid Beels and Michael Schwern":http://opensourcebridge.org/sessions/484 at the last Open Source Bridge opened the industry's eyes to the fact that most web applications are inherently insecure. Any application that sends requests over plain HTTP and that uses cookies to track user sessions is vulnerable to "session hijacking":http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_theft_and_session_hijacking.

  Many applications have reacted to this by offering options to run all traffic through HTTPS. Examples include Gmail, Github, Facebook, and Twitter. Using HTTPS does go a long way in improving web application security. But in most cases HTTPS security is opt-in - probably due to difficulties in rolling out HTTPS on a large scale and added application complexity. This means that only relatively paranoid users benefit. Less fortunate users, like Ashton Kutcher, will often be "left vulnerable":http://techcrunch.com/2011/03/15/twitter-enables-always-use-https-setting/.

  Furthermore, HTTPS by itself does little to protect against "cross-site request forgery":http://en.wikipedia.org/wiki/Cross-site_request_forgery. It is still necessary for developers to use "form tokens":http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/, "JSON obfuscation":http://directwebremoting.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascript_service.html, and the like to protect application resources. This results in extra complexity and statefulness.

  CSRF(cross-site request forgery) does not just force complexity though. Its existence actively stifles innovation. The new "cross-origin resource sharing specification":http://www.w3.org/TR/cors/, which allows servers to opt-into cross-origin XHR(XMLHttpRequest) requests, presents many possibilities for rich interaction between web applications. Unfortunately this specification is infrequently used because it opens up XHR(XMLHttpRequest) as another vector for CSRF(cross-site request forgery) attacks in cases where cookie authentication is used. In the eyes of many developers this is just too dangerous to justify exploring a new technology.

  All of these problems are products of the fundamental design of cookie authentication: what is essentially a temporary password is transmitted with every web request and that password is easily accessed - directly by eavesdroppers or indirectly by third-party web pages.

  There are better options. There are now pure JavaScript implementations of various cryptographic algorithms, including "SHA-1":http://en.wikipedia.org/wiki/SHA-1, "SHA-256":http://en.wikipedia.org/wiki/Sha-256, "AES":http://en.wikipedia.org/wiki/Advanced_Encryption_Standard, and "RSA":http://en.wikipedia.org/wiki/RSA. There are also well-studied authentication mechanisms built on top of those algorithms designed specifically to prevent man-in-the-middle attacks, like session hijacking. And an authentication mechanism based on JavaScript rather than cookie data would be far less vulnerable to CSRF(cross-site request forgery).

  I will explore authentication mechanisms such as "HMAC":http://en.wikipedia.org/wiki/Hmac, as seen in "OAuth":http://oauth.net/, and block cipher authentication, e.g. "CMAC":http://en.wikipedia.org/wiki/CMAC. I will present on the applicability and feasibility of implementing these solutions in JavaScript in ordinary web applications. I will analyze performance and cross-browser compatibility considerations. Finally, I will demonstrate my own recommendation for next-generation browser authentication.

  • Browsers
  • JavaScript
  • OAuth
  • Security
  • Web

  At 1:30pm to 2:15pm, Thursday 23rd June

  Coverage note