This presentation was by Rohit Sethi, the Project Leader for the Secure Pattern Analysis Project at OWASP and he works at Security Compass, a security analysis and training company.  My notes from the session are below:

  • Before anyone starts building complex systems, they need to design.
  • We create threat models on completed designs.
  • What about during design?
  • Book: “Core J2EE Patterns Best Practices and Design Strategies”
  • If you use J2EE development, chances are you’re using patterns documented here
  • Core J2EE patterns are used extensively
  • Patterns are used in JSF, Velocity, Struts, Tapestry, Spring, and Proprietary Frameworks

Example: Project: Analyze Patterns

Use to Implement:

  • Synchronization Tokens as Anti-CSRF Mechanism
  • Page-level authorizations

Avoid:

  • XSLT and Xpath vulnerabilities
  • XML Denial of Service
  • Disclosure of information in SOAP faults
  • Publishing WSDL files
  • Unhandled commands
  • Unauthorized commands

Project Goals

  • Analyze patterns for security pitfalls to avoid
  • Determine how patterns can implement security controls
  • Provide advice portable to most frameworks

A security pattern is not the same as a security analysis of a pattern.

Uses

  • Designing new web application frameworks (make the next generation of frameworks secure by default)
  • Designing new apps that use the patterns
  • Source code review of existing apps
  • Runtime assessment of existing apps
  • Integrate with threat modeling of new or existing apps

You can help:

  • Tell developers
  • Improve the analysis

Next Steps?

  • Add code review and examples to the existing pattern book
  • Look at other pattern books to see if there are other patterns that we should analyze

Our Dream

  • New web application framework idea + Design-time security analysis = Secure-by-default web application framework