OWASP Secure Application Design Project
- Methodology of Design Review
- Design Flaws - Web
- Road Map and Getting Involved
- Project About
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 - 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:
- 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.
This section describes some of the important design flaws that can leave a backdoor in the application to access it without authentication or manipulate its business logic. We will understand such flaws and secure design recommendations in detail.
Data Binding Technique
Another popular feature seen in most of the design frameworks today is data binding, where the request parameters get directly bound to the variables of the corresponding business/command object. Binding here means that the instance variables of such classes get automatically initialized with the request parameter values based on their names. Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.
What is the flaw?
The flaw in such design could be that the business objects may have variables that are not dependent on the request parameters. Such variables could be key variables like price, max limit, role etc. having static values or dependent on some server side processing logic. A threat in such scenarios is that an attacker may supply additional parameters in request and try to bind values for unexposed variable of business object class. As illustrated in the figure below, the attacker sends an additional “price” parameter in the request and binds with the unexposed variable “price” in business object, thereby manipulating business logic.
Secure Design Recommendation:
- An important point to be noted here is that the business/form/command objects must have only those instance variables that are dependent on the user inputs. If additional variables are present those must not be vital ones like related to the business rule for the feature.
- In any case the application must accept only desired inputs from the user and the rest must be rejected or left unbound. And initialization of unexposed of variables, if any must take place after the binding logic.
Review the application design and check it is incorporates a data binding logic. In case it does, check if business objects/beans that get bound to the request parameters have unexposed variables that are meant to have static values. If such variables are initialized before the binding logic this attack will work successfully.
Placement of Security Controls
Placement of security checks is a vital area of review in an application design. Incorrect placements can render the applied security controls null and void. So, it is important to study the application design and spot the correctness of such checks in the overall execution flow of the design. Most of the application designs are based on the concept of Model-View-Controller (MVC). They have a central controller, which listens to all incoming request and delegates control to appropriate form/business processing logic. And ultimately the user is rendered with a view. In such a layered design, when there are many entities involved in processing a request, developers often go wrong in placing the security controls at the right place. Most application developers feel “view” is the right place to have the security checks like authentication check etc.
What is the flaw?
It thus seems logical that if you restrict the users at the page/view level they won’t be able to perform any operation in the application. But what if instead of requesting for a page/view an unauthorized user tries to request for an internal action like to action to add/modify any data in the application? It will get processed but the resultant view will be denied to the user; because the flaw lies in just having a view based access control in the applications. I am sure you will agree that a lot of processing for a request is done before the “view” comes into picture in any design. So the request to process any action will get processed successfully without authorization.
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. Observe that neither the controller servlet (central processing entity) nor the action classes have any access control checks. So here, if the user requests for an internal action like add user details, etc. without authentication it will get processed, but the only difference is that the user will be shown an error page as resultant view will be disallowed to the user.
Insecure POST-BACK’s in ASP.NET
A similar flaw is predominantly observed in ASP.NET applications where the developers tend to mix the code for handling POSTBACK’s and authentication checks. Usually it is observed that the authentication check in the ASP.NET pages are not applied for POSTBACKs, as indicated below. Here, if an attacker tries to access the page without authentication an error page will be rendered. Instead, if the attacker tries to send an internal POSTBACK request directly without authentication it would succeed. A detailed explanation is present here -[]
Secure Design Recommendation:
Do not just restrict the access of the users only over views. It is imperative to place all validation checks before processing any business logic and in case of ASP.NET applications independent of the POSTBACKs.
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.
Execution flow is another important consideration of design. The execution flow must terminate appropriately in case of an error condition. However, due to mishandling of some programming entities there could be a big hole in the application which would allow unrestricted access to applications. One such flaw is related to – “sendRedirect” method in J2EE applications.
This method is used to send a redirection response to the user who then gets redirected to the desired web component, whose ULR is passed as an argument to the method –in this case home.html. One such misconception is that execution flow in the Servlet or JSP page that is redirecting the user stops after a call to this method.
Take a look at the code snippet below, it checks for authenticated session using an “if” condition. If the condition fails the response.sendRedirect() is used to redirect the user to an error page. Note that there is code present after the If condition, which continues to fetch request parameters and processes business logic for instance adding a new branch entry of a bank in this case.
What is the flaw?
This flaw manifests as a result of the misconception that the execution flow in the JSP/Servlet page stops after the “sendRedirect” call. However it does not; in this case the execution of the servlet would continue even if an invalid session is detected by the “if” condition and thus the business logic will get processed for unauthenticated requests.
Note: The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class. However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.
Secure Design Recommendation:
Since this flaw results from the assumption made by developers that control flow execution terminates after a sendRedirect call, the recommendation would be to terminate the flow using a “return” statement.
Check if there is an appropriate logic to terminate the execution flow is present in case of an error condition. Check for similar instances of insecure security controls built using “sendRedirect” method.
Some links for reference:
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?