Difference between revisions of "OWASP Secure Application Design Project"

From OWASP
Jump to: navigation, search
(Created page with "=Main= Project Leader’s content goes here =Project About= {{:Projects/OWASP_Secure_Application_Design_Project}} Category:OWASP Project")
 
Line 1: Line 1:
=Main=
+
=INTRODUCTION =
Project Leader’s content goes here
+
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.
 +
 
 +
=UNDERSTANDING THE DESIGN=
 +
'''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.
 +
 
 +
=METHODOLOGY OF DESIGN REVIEW=
 +
The methodology to be followed for design reviews is explained below:
 +
[[File:Design.png]]
 +
 
 +
=='''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.
 +
 
 +
# Data Flow/Code Layout
 +
# Access control
 +
# Existing/Built-in Security controls
 +
# Entry points of non-user inputs
 +
# Integrations with external services
 +
# Location of configurations file and data sources
 +
# 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:
 +
# Data Flow -
 +
## Are user inputs used to directly reference a business logic class/function
 +
## Is there a data binding flaw?
 +
## Does it expose any backdoor parameter to invoke business logic?
 +
## Is the execution flow of the application correct?
 +
# Authentication and access control -
 +
## Does the design implement access control for all the files?
 +
## Does it handle session securely?
 +
## Is there SSO, does it leave any backdoor?
 +
# Existing/built-in Security Controls -
 +
## Weakness in any existing security control
 +
## Is the placement of the security controls correct?
 +
# Architecture –
 +
## Is there validation for all input sources?
 +
## Is the connection to external servers secure?
 +
#Configuration/code files and datastores -
 +
## Are sensitive data present in configuration files?
 +
## Does it support any insecure data source?
 +
 
 +
A detailed checklist is available here - [[File:Checklist For Design.pdf]].
 +
 
 +
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:
 +
# Elaborate validation strategy with respect to:
 +
##Identifying right application component like servlet filters, interceptors, validator classes etc.
 +
##Placement of check
 +
## Validation mechanism
 +
## Use of 3rd party security API’s or inbuilt design features of the frameworks
 +
# Encryption techniques
 +
# 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.
  
 
=Project About=
 
=Project About=

Revision as of 13:34, 29 May 2013

Contents

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.

UNDERSTANDING THE DESIGN

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.

METHODOLOGY OF DESIGN REVIEW

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

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 - File:Checklist For Design.pdf.

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.

Project About

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
  • Contact the GPC to report a problem or concern about this project or to update information.
current release
last reviewed release
Not Yet Reviewed


other releases