OWASP Secure Application Design Project

=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:



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 -
 * 2) Are user inputs used to directly reference a business logic class/function
 * 3) Is there a data binding flaw?
 * 4) Does it expose any backdoor parameter to invoke business logic?
 * 5) Is the execution flow of the application correct?
 * 6) Authentication and access control -
 * 7) Does the design implement access control for all the files?
 * 8) Does it handle session securely?
 * 9) Is there SSO, does it leave any backdoor?
 * 10) Existing/built-in Security Controls -
 * 11) Weakness in any existing security control
 * 12) Is the placement of the security controls correct?
 * 13) Architecture –
 * 14) Is there validation for all input sources?
 * 15) Is the connection to external servers secure?
 * 16) Configuration/code files and datastores -
 * 17) Are sensitive data present in configuration files?
 * 18) Does it support any insecure data source?

A detailed checklist is available here -.

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: And so on depending on the control to be built in the design.
 * 1) Elaborate validation strategy with respect to:
 * 2) Identifying right application component like servlet filters, interceptors, validator classes etc.
 * 3) Placement of check
 * 4) Validation mechanism
 * 5) Use of 3rd party security API’s or inbuilt design features of the frameworks
 * 6) Encryption techniques
 * 7) Design Patterns

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=