OWASP Secure Application Design Project

• Main
• Methodology of Design Review
• FAQs
• Acknowledgements
• Road Map and Getting Involved
• Project About

OWASP Secure Application Design Project OWASP Secure Application Design Project is... Introduction This project highlights some of the vital areas of design security. We are all aware of “secure coding” and practice it to great extent while developing applications. But do we give equal attention to – “Secure Design”? Most of us would probably say, NO. Design level flaws are lesser known concepts but their presence is a very big risk to the applications. Such flaws are hard to find in static or dynamic application scans and instead require deep understanding of application architecture and layout to uncover them manually. With increasing business needs the complexities in application design and architecture are also increasing. There is a rise in the use of custom design techniques and diverse technologies in the applications today, which makes the need for design reviews imperative. This project focuses on highlighting some important secure design principles that developers and architects must adapt to build a secure application design. With the help of some design flaws we will see the areas of design that are exposed to security risks and what measures can be taken to avoid them in our design. It also includes mitigation techniques that can be implemented in the applications to prevent them. Description What is an application design? A design is a blueprint of an application; it lays a foundation for its development. It illustrates the layout of the application and identifies different application components needed for it. It is a structure that determines execution flow of the application. Most of the application designs are based on a concept of MVC. In such designs different components interact with each other in an ordered sequence to serve any user request. Why should be review the design? Design review should be an integral part of secure software development process. If the application is reviewed for security at the design level many inherent backdoors can be uncovered. Design reviews also help to implementing the security requirements in a better way. What is Secure Application Design? Design level flaws are lesser known concepts but their presence is a very big risk to the applications. Such flaws are hard to find in static or dynamic application scans and instead require deep understanding of application architecture and layout to uncover them manually. Design level security is crucial and must be adopted at an early stage of application development to build a robust system. Thus the aim of this project is to impart secure design guidelines to application developers. The project will highlight vulnerable areas in application designs through real world examples and scenarios and touch up on different aspects of design level security. The focus will also be to explain measures to be taken to prevent such flaws while designing applications. The guidelines will cover core design concepts which can applicable to any application independent of the platform. Most of the design flaws will be discussed using sample code incorporated in an insecure design application. The project will also focus on releasing a secure design checklist for reviewing application designs or threat modelling them.

Licensing OWASP Secure Application Design Project is free to use. It is under an Apache 2.0 License (fewest restrictions, even allowing proprietary modifications and proprietary forks of your project Presentation Project Leader Ashish Rao Related Projects Ohloh

Quick Download Application Design Flaws - Web Secure Application Design Checklist Email List Sign Up News and Events [20 Nov 2013] News 2 [30 Sep 2013] News 1 Classifications

The methodology to be followed for design reviews is explained below:

Collection of Design Documents

This phase involves collecting required information of the proposed design. It would involve all kinds of documentation maintained by the development team about the design like flow charts, sequence diagrams, class diagrams etc. Requirements documents are also needed to understand the objective of the proposed design.

Design Study

In this phase the design is thoroughly studied mainly with respect to the data flow, different application components and their interactions, data handling etc. This is achieved through manual analysis and discussions with the design or technical architect’s team. The design and the architecture of the application must be understood thoroughly to analyse vulnerable areas that can lead to security breaches in the application. The key areas of the design that must be considered during threat analysis are given below.

1. Data Flow/Code Layout
2. Access control
3. Existing/Built-in Security controls
4. Entry points of non-user inputs
5. Integrations with external services
6. Location of configurations file and data sources
7. Add-ons and customization present (in case of built-in design framework)

This will help in identifying the trust boundaries for an application and thus aid in taking decisions about the vulnerabilities and their risk levels posed to the application.

Design Analysis

After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.

The threats must be identified for different design areas that were identified in the previous step. It involves observing the design from an attacker’s perspective and uncovering the backdoors and insecure areas present in it. The analysis can be done broadly on the basis of 2 important criteria:

1. Insecure Implementation – This would mean the design has a loophole which can lead to a security breach in the application. For instance, insecure reference to business logic functions.

2. Lack of secure implementation – This would mean the design has not incorporated secure practices. For instance, in connection to external server different security requirements to protect confidentiality and integrity of the data are not present.

Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:

1. Data Flow -
   1. Are user inputs used to directly reference a business logic class/function
   2. Is there a data binding flaw?
   3. Does it expose any backdoor parameter to invoke business logic?
   4. Is the execution flow of the application correct?
2. Authentication and access control -
   1. Does the design implement access control for all the files?
   2. Does it handle session securely?
   3. Is there SSO, does it leave any backdoor?
3. Existing/built-in Security Controls -
   1. Weakness in any existing security control
   2. Is the placement of the security controls correct?
4. Architecture –
   1. Is there validation for all input sources?
   2. Is the connection to external servers secure?
5. Configuration/code files and datastores -
   1. Are sensitive data present in configuration files?
   2. Does it support any insecure data source?

A detailed checklist is available here - Secure Application Design Checklist.

At the end of this activity we get a list of threats or insecure areas applicable to the design.

Propose Security Requirements

After analysing the insecure areas in the design in this step a list of security requirements corresponding to them must be created. Requirements are high level changes or additions to be incorporated in the design, for instance: Validate the inputs fetched from the webservice response before processing them. Any protection that is needed for resolving the vulnerable area identified in the design would go as a security requirement for the design. This phase involves listing all the security requirements for the design along with security risk associated with them. This risk based approach would help the development teams in prioritizing the security requirements.

Recommend Design Changes

In this phase every security requirement must be associated with a security control. A security control best suited for the design is proposed and documented. These security controls are an elaborate view of the security requirements. Here, we would identify exact changes or additions to be incorporated in the design that are needed to meet any requirement or mitigate a threat. The changes or controls recommended for the design should be clear and detailed, as given in the instances below:

1. Elaborate validation strategy with respect to:
   1. Identifying right application component like servlet filters, interceptors, validator classes etc.
   2. Placement of check
   3. Validation mechanism
   4. Use of 3rd party security API’s or inbuilt design features of the frameworks
2. Encryption techniques
3. Design Patterns

And so on depending on the control to be built in the design.

Discussion with the design team

The list of security requirements and proposed controls must be then discussed with the development teams. The queries of the teams should be addressed and feasibility of incorporating the controls must be determined. Exceptions, if any must be taken into account and alternate recommendations should be proposed. In this phase a final agreement on the security controls is achieved.

Design Finalization

The final design incorporated by the development teams must be reviewed again and finalized for further development process.

Q1

A1

Q2

A2

Volunteers

Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:

• xxx
• xxx

Others

• xxx
• xxx

As of May 2014, the priorities are:

• xxx
• xxx
• xxx

Involvement in the development and promotion of the Secure Application Design is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:

• xxx
• xxx

PROJECT INFO What does this OWASP project offer you?

RELEASE(S) INFO What releases are available for this project?

what is this project? Name: OWASP Secure Application Design Project (home page) Purpose: Design level flaws are lesser known concepts but their presence is a very big risk to the applications. Such flaws are hard to find in static or dynamic application scans and instead require deep understanding of application architecture and layout to uncover them manually. Design level security is crucial and must be adopted at an early stage of application development to build a robust system. Thus the aim of this project is to impart secure design guidelines to application developers. The project will highlight vulnerable areas in application designs through real world examples and scenarios and touch up on different aspects of design level security. The focus will also be to explain measures to be taken to prevent such flaws while designing applications. The guidelines will cover core design concepts which can applicable to any application independent of the platform. Most of the design flaws will be discussed using sample code incorporated in an insecure design application. The project will also focus on releasing a secure design checklist for reviewing application designs or threat modelling them. License: Apache 2.0 License (fewest restrictions, even allowing proprietary modifications and proprietary forks of your project) who is working on this project? Project Leader(s): Ashish Rao @ how can you learn more? Project Pamphlet: Not Yet Created Project Presentation: Mailing list: Mailing List Archives Project Roadmap: View Key Contacts Contact Ashish Rao @ to contribute to this project Contact Ashish Rao @ to review or sponsor this project

current release last reviewed release Not Yet Reviewed other releases