Difference between revisions of "Category:OWASP Security Analysis of Core J2EE Design Patterns Project"

From OWASP
Jump to: navigation, search
m
Line 34: Line 34:
  
 
<p>Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book. We hope our guide will help address the critical shortage of advice on securely coding using existing design patterns. Your feedback is critical to improving the quality and applicability of the best practices listed in the Security Analysis of Core J2EE Design Patterns. Please contact the authors at labs@securitycompass.com with comments or questions and help improve the guide for future developers.</p>
 
<p>Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book. We hope our guide will help address the critical shortage of advice on securely coding using existing design patterns. Your feedback is critical to improving the quality and applicability of the best practices listed in the Security Analysis of Core J2EE Design Patterns. Please contact the authors at labs@securitycompass.com with comments or questions and help improve the guide for future developers.</p>
 +
 +
==== Presentation-tier Patterns ====
 +
 +
;INTERCEPTING FILTER
 +
:The Intercepting Filter pattern may be used in instances where there is the need to execute logic before and after the main processing of a request (pre and postprocessing).  The logic resides in Filter objects and typically consist of code that is common across multiple requests.  The Servlet 2.3 Specification provides a mechanism for building filters and chaining of Filters through configuration.  A FilterManager controls the execution of a number of loosely-coupled Filters (referred to as a FilterChain), each of which performs a specific action.  This Standard Filter Strategy can also be replaced by a Custom Filter Strategy which replaces the Servlet Specification’s object wrapping with a custom implementation.
 +
  
 
__NOTOC__
 
__NOTOC__
 
<headertabs/>
 
<headertabs/>

Revision as of 07:03, 2 July 2009

Main

Project Roadmap

  • The project’s overall goal is to...
    • Be a design-time security reference for developers implementing common patterns independent of specific platforms and frameworks. Pattern usage is ubiquitous in software development, and the best patterns transcend specific languages and/or frameworks; analyzing the most pivotal frameworks in web applications allows us to build security advice that developers will use far in the future. At the same time, analyzing common patterns helps manual penetration testers and source code reviewers understand where to look for vulnerabilities within an application.
  • In the near term, we are focused on the following tactical goals...

1. Convert existing Core J2EE Patterns analysis word document into wiki format,

2. Solicit feedback and add additional advice to each pattern,

3. Determine next steps in group:

3.1. Add source code examples,

3.2. Start reviewing other patterns, such as Patterns of Enterprise Application Architecture, Enterprise Integration Patterns, or .Net Patterns.



Project Identification

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What does this OWASP project release offer you?
what is this project?
OWASP Security Analysis of Core J2EE Design Patterns Project

Purpose: To analyze popular design and architectural patterns for potential security issues, including advice on common pitfalls to avoid and where in a pattern to implement common security controls. Note that we are not creating new “security patterns” but rather analyzing existing non-security-specific patterns.

Project License: GPL v3

who is working on this project?
Project Leader: Rohit Sethi

Project Maintainer: Rohit Sethi, Jim Manico

Project Contributor(s): Sahba Kazerooni, Krish Raja, Subu Ramanathan, Oliver Lavery, Frank Kim

how can you learn more?

3x slide presentation: To do

Project Flyer/Pamphlet: To do

Mail list: Subscribe or read the archives

Project Roadmap: To view, click here

Project main links: http://www.corej2eepatterns.com/Patterns2ndEd/index.htm

Project Health: Yellow button.JPG Not reviewed

Reviewed under: Assessment Criteria v2.0

Key Contacts
  • Contact Rohit Sethi to contribute to this project,
  • Contact Rohit Sethi or GPC to review or sponsor this project,
  • Contact GPC to report a problem or concern about this project or to update information.
current Release
First Release - July 2009 - TODO - add link to download

Release Leader: Rohit Sethi

Release details: Main links, release roadmap and assessment

Release Rating: Yellow button.JPG Not reviewed/Targeted at Stable Release
Reviewed under Assessment Criteria v2.0


Introduction

Most application security experts focus on a single activity for integrating design into the SDLC: threat modeling . Threat modeling is excellent at approximating an application’s attack surface but, in our experience, developers sometimes do not have the time, budget or security know-how to build an adequate threat model. Perhaps more importantly, developers cannot create a comprehensive threat model until they complete the application design.

This reference guide aims at dispensing security best practices to developers to make security decisions during design. We focus on one of the most important concepts in modern software engineering: design patterns. Ever since the publication of the seminal Design Patterns Book , developers have reused common patterns such as Singleton and Factory Method in large-scale software projects. Design patterns offer a common vocabulary to discuss application design independent of implementation details. One of the most critically acclaimed pattern collections in the Java Enterprise Edition (JEE) community is the Core J2EE Patterns book by Deepak Alur, Dan Malks and John Crupi . Developers regularly implement patterns such as “Application Controller”, “Data Access Object” or “Session Façade” in large, distributed JEE applications and in frameworks such as Spring and Apache Struts . We aim to dispense security best practices so that developers can introduce security features and avoid vulnerabilities independent of their underlying technology choices such as which Model View Controller (MVC) framework to use.

Java developers currently have access to patterns for security code (e.g. how to develop authentication, how to implement cryptography) such as the Core Security Patterns book. We hope our guide will help address the critical shortage of advice on securely coding using existing design patterns. Your feedback is critical to improving the quality and applicability of the best practices listed in the Security Analysis of Core J2EE Design Patterns. Please contact the authors at labs@securitycompass.com with comments or questions and help improve the guide for future developers.

Presentation-tier Patterns

INTERCEPTING FILTER
The Intercepting Filter pattern may be used in instances where there is the need to execute logic before and after the main processing of a request (pre and postprocessing). The logic resides in Filter objects and typically consist of code that is common across multiple requests. The Servlet 2.3 Specification provides a mechanism for building filters and chaining of Filters through configuration. A FilterManager controls the execution of a number of loosely-coupled Filters (referred to as a FilterChain), each of which performs a specific action. This Standard Filter Strategy can also be replaced by a Custom Filter Strategy which replaces the Servlet Specification’s object wrapping with a custom implementation.


This category currently contains no pages or media.