OWASP Secure Application Design Project
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.
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.
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.
The final design incorporated by the development teams must be reviewed again and finalized for further development process.
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:
As of May 2014, the priorities are:
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:
| PROJECT INFO
What does this OWASP project offer you?
| RELEASE(S) INFO|
What releases are available for this project?