https://wiki.owasp.org/api.php?action=feedcontributions&user=Ashish+Rao&feedformat=atomOWASP - User contributions [en]2024-03-29T02:39:54ZUser contributionsMediaWiki 1.27.2https://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195977OWASP Secure Application Design Project2015-06-09T18:36:11Z<p>Ashish Rao: /* Business Logic Invocation Technique */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
[[File:Design5.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
[[File:Design6.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. <br />
<br />
[[File:Design7.png]]<br />
<br />
Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
[[File:Design8.png]]<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
[[File:Design9.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195976OWASP Secure Application Design Project2015-06-09T18:34:45Z<p>Ashish Rao: /* Placement of Security Controls */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
[[File:Design5.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
[[File:Design6.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. <br />
<br />
[[File:Design7.png]]<br />
<br />
Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
[[File:Design8.png]]<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
[[File:Design9.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195975OWASP Secure Application Design Project2015-06-09T18:34:13Z<p>Ashish Rao: /* Placement of Security Controls */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
[[File:Design5.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
[[File:Design6.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. <br />
[[File:Design7.png]]<br />
<br />
Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
[[File:Design8.png]]<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
[[File:Design9.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design9.png&diff=195974File:Design9.png2015-06-09T18:33:57Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design8.png&diff=195973File:Design8.png2015-06-09T18:32:49Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design7.png&diff=195972File:Design7.png2015-06-09T18:32:04Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design5.png&diff=195971File:Design5.png2015-06-09T18:28:39Z<p>Ashish Rao: Ashish Rao uploaded a new version of &quot;File:Design5.png&quot;</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design6.png&diff=195970File:Design6.png2015-06-09T18:28:10Z<p>Ashish Rao: Ashish Rao uploaded a new version of &quot;File:Design6.png&quot;</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design6.png&diff=195969File:Design6.png2015-06-09T18:23:16Z<p>Ashish Rao: Ashish Rao uploaded a new version of &quot;File:Design6.png&quot;</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design6.png&diff=195968File:Design6.png2015-06-09T18:19:44Z<p>Ashish Rao: Ashish Rao uploaded a new version of &quot;File:Design6.png&quot;</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195967OWASP Secure Application Design Project2015-06-09T18:17:15Z<p>Ashish Rao: /* Model Object Binding Technique */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
[[File:Design5.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
[[File:Design6.png]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design6.png&diff=195966File:Design6.png2015-06-09T18:16:52Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design5.png&diff=195965File:Design5.png2015-06-09T18:15:56Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195964OWASP Secure Application Design Project2015-06-09T18:15:09Z<p>Ashish Rao: /* Business Logic Invocation Technique */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195963OWASP Secure Application Design Project2015-06-09T18:14:44Z<p>Ashish Rao: /* Business Logic Invocation Technique */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
[[File:Design1.png]]<br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
[[File:Design2.jpg]]<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
[[File:Design3.jpg]]<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
[[File:Design4.png]]<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design4.png&diff=195962File:Design4.png2015-06-09T18:14:18Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design3.jpg&diff=195961File:Design3.jpg2015-06-09T18:13:52Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design2.jpg&diff=195960File:Design2.jpg2015-06-09T18:13:21Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design1.png&diff=195959File:Design1.png2015-06-09T18:11:34Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195958OWASP Secure Application Design Project2015-06-09T18:05:23Z<p>Ashish Rao: </p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<img1><br />
<br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
'''Consider another scenario - Method Invocation'''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
'''What is the flaw?'''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class. <br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
'''CASE 1:''' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
'''CASE 2:''' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
'''CASE 3:''' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=195957OWASP Secure Application Design Project2015-06-09T18:02:59Z<p>Ashish Rao: /* Design Flaws - Web */</p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:105px;border:0,margin:0;overflow: hidden;">[[Image:Low activity.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Low_Activity_Projects]] </div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
This section describes some of the important design flaws are lesser known facts and can inadvertently leave a leave a backdoor in the application. We will understand the security flaws that can creep in while developing MVC applications.<br />
<br />
A design of an application determines how different classes and files interact with each other to serve any user request. It is a structure that determines execution flow in the application. Most of the application designs are based on a concept of MVC. <br />
<br />
The design and the architecture of the application must be understood thoroughly to analyze 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.<br />
• Data Flow/Code Layout<br />
• Placement of security controls<br />
• Entry points of non-user inputs<br />
• Integrations with external services<br />
• Location of configurations file and data sources<br />
• Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
''Introduction''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application. <br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class.<br />
<img1><br />
<br />
''What is the flaw?''<br />
<br />
A flaw in such a design could be that unused configurations may be present in the configuration file that can be accessed by an attacker. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
''Consider another scenario - Method Invocation''<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class.<br />
<br />
''What is the flaw?''<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
The applications must ensure to:<br />
• Remove ALL redundant/test/unexposed business logic configurations from the file<br />
• Apply necessary authorization check before processing business logic method<br />
• Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
''Review Criteria''<br />
<br />
With a view of the above mentioned factors we must carefully evaluate the design of any application to determine whether user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
• Business logic class<br />
• Method names<br />
• View component<br />
<br />
In such case identify unexposed configurations and business logic methods as per the user privileges (wherever applicable) and attempt to access them.<br />
<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class. <br />
<br />
==Model Object Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
Another popular feature seen in most of the design frameworks today is binding of model objects with user inputs. Here 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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
==Backdoor Parameters/ Business Logic Decision based on User input==<br />
<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. There are 3 such cases listed below:<br />
<br />
''CASE 1:'' The application must not depend on non-editable controls, drop-down menus or hidden fields for business logic processing. It is a secure practice to use the business logic parameters like price, max limit etc. from the server side. Even if the application sends these parameters as non-editable, select or hidden parameters it must maintain a separate copy of such values at the server side and use the same for business logic processing. <br />
The users can easily alter such parameter values and try to manipulate business logic.<br />
<br />
''CASE 2:'' At times applications tend to make logical decisions merely on the basis of the values of certain request parameters. Such parameters are often the once indicating the type of the user, nature of the request, status of the transaction, etc. The application must not expose such parameters to the users. Even if they are exposed, the application must not rely on request parameters for logical decisions and analyse the same from server side processing.<br />
The users can easily manipulate such parameter values and try to evade business logic validations or elevate privileges in the application. <br />
<br />
''CASE 3:'' Some application developers believe in the concept of – “what is hidden is secure”. They decide on the visibility of the some input fields for the features based on the role/privilege level of the logged-in user. This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behaviour of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. Thus there exists a loophole in such applications where the server side behaviour can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=Projects/OWASP_Secure_Application_Design_Project/Releases/Current&diff=174409Projects/OWASP Secure Application Design Project/Releases/Current2014-05-06T18:29:57Z<p>Ashish Rao: Blanked the page</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=174408OWASP Secure Application Design Project2014-05-06T18:26:27Z<p>Ashish Rao: </p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
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.<br />
==Data Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
Some links for reference:<br />
*http://artechtalks.blogspot.in/<br />
*http://packetstormsecurity.com/files/119129/Insecure-Authentication-Control-In-J2EE.html<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=174407OWASP Secure Application Design Project2014-05-06T18:24:40Z<p>Ashish Rao: </p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/index.php/Projects/OWASP_Secure_Application_Design_Project/Releases/Current Application Design Flaws - Web]<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
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.<br />
==Data Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
Some links for reference:<br />
*http://artechtalks.blogspot.in/<br />
*http://packetstormsecurity.com/files/119129/Insecure-Authentication-Control-In-J2EE.html<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=174406OWASP Secure Application Design Project2014-05-06T18:23:45Z<p>Ashish Rao: </p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/index.php/Projects/OWASP_Secure_Application_Design_Project/Releases/Current Application Design Flaws - Web]<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Design Flaws - Web=<br />
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.<br />
==Data Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
Some links for reference:<br />
*http://artechtalks.blogspot.in/<br />
*http://packetstormsecurity.com/files/119129/Insecure-Authentication-Control-In-J2EE.html<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=174405OWASP Secure Application Design Project2014-05-06T18:14:52Z<p>Ashish Rao: </p>
<hr />
<div>=Main=<br />
<br />
<div style="width:100%;height:160px;border:0,margin:0;overflow: hidden;">[[File:OWASP_Project_Header.jpg|link=]]</div><br />
<br />
{| style="padding: 0;margin:0;margin-top:10px;text-align:left;" |-<br />
| valign="top" style="border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==OWASP Secure Application Design Project==<br />
<br />
OWASP Secure Application Design Project is...<br />
<br />
==Introduction==<br />
<br />
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.<br />
<br />
==Description==<br />
'''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.<br />
<br />
'''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.<br />
<br />
<br />
<br />
== What is Secure Application Design? ==<br />
<br />
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.<br />
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.<br />
The guidelines will cover core design concepts which can applicable to any application independent of the platform.<br />
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.<br />
<br />
| valign="top" style="padding-left:25px;width:200px;border-right: 1px dotted gray;padding-right:25px;" |<br />
<br />
==Licensing==<br />
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<br />
<br />
== Presentation ==<br />
<br />
<br />
== Project Leader ==<br />
<br />
[mailto:ashish.rao@owasp.org Ashish Rao]<br />
<br />
<br />
== Related Projects ==<br />
<br />
<br />
== Ohloh ==<br />
<br />
| valign="top" style="padding-left:25px;width:200px;" | <br />
<br />
== Quick Download ==<br />
<br />
* [https://www.owasp.org/index.php/Projects/OWASP_Secure_Application_Design_Project/Releases/Current Application Design Flaws - Web]<br />
* [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist]<br />
<br />
== Email List ==<br />
<br />
[https://lists.owasp.org/mailman/listinfo/owasp_secure_application_design Sign Up]<br />
<br />
== News and Events ==<br />
* [20 Nov 2013] News 2<br />
* [30 Sep 2013] News 1<br />
<br />
<br />
==Classifications==<br />
<br />
{| width="200" cellpadding="2"<br />
|-<br />
| align="center" valign="top" width="50%" rowspan="2"| [[File:New projects.png|100px|link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Incubator_Projects]]<br />
| align="center" valign="top" width="50%"| [[File:Owasp-builders-small.png|link=]] <br />
|-<br />
| align="center" valign="top" width="50%"| [[File:Owasp-defenders-small.png|link=]]<br />
|-<br />
| colspan="2" align="center" | [[File:Cc-button-y-sa-small.png|link=http://creativecommons.org/licenses/by-sa/3.0/]]<br />
|-<br />
| colspan="2" align="center" | [[File:Project_Type_Files_CODE.jpg|link=]]<br />
|}<br />
<br />
|}<br />
<br />
=Methodology of Design Review=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[Image:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [https://www.owasp.org/images/f/f7/Checklist_For_Design.pdf Secure Application Design Checklist].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=FAQs=<br />
<br />
; Q1<br />
: A1<br />
<br />
; Q2<br />
: A2<br />
<br />
= Acknowledgements =<br />
==Volunteers==<br />
Secure Application Design is developed by a worldwide team of volunteers. The primary contributors to date have been:<br />
<br />
* xxx<br />
* xxx<br />
<br />
==Others==<br />
* xxx<br />
* xxx<br />
<br />
= Road Map and Getting Involved =<br />
As of May 2014, the priorities are:<br />
* xxx<br />
* xxx<br />
* xxx<br />
<br />
Involvement in the development and promotion of the Secure Application Design is actively encouraged!<br />
You do not have to be a security expert in order to contribute.<br />
Some of the ways you can help:<br />
* xxx<br />
* xxx<br />
<br />
<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
<br />
__NOTOC__ <headertabs /> <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=CRV2_CanStaticAnalyzersDoAll&diff=156393CRV2 CanStaticAnalyzersDoAll2013-08-04T19:07:05Z<p>Ashish Rao: </p>
<hr />
<div>Secure code review is a process of enumerating the flaws in the application. The flaws may exist in the application due to insecure code, design or configuration. Out of which the flaws that arise due to insecure code can be enumerated to a great extent through automated analysis, as most of them are associated with insecure patterns. <br />
<br />
Automated analysis can be carried out through any of the following three options:<br />
<br />
*Static Code analyzers or scanners<br />
*Custom scripts based on some pattern search<br />
*Open source tools<br />
<br />
Though some scripts and some open source tools are efficient enough in finding insecure code patterns but they often lack the capability of tracing the data flow. This limitation is fulfilled by the use of static code analyzers or the scanners, which identify the insecure code pattern along with source to the sink analysis. <br />
<br />
'''With this we come to the next big question i.e. Can scanners i.e. static code analyzers do it all?''' <br />
<br />
Static code analyzers or the scanners are the most comprehensive options to automate the process of review. <br />
<br />
Some of the advantages of static code scanners are:<br />
<br />
'''1. Reduction in manual efforts '''– Secure code review can be at times be a tedious process of analyzing thousands of lines of code for a host of vulnerabilities. Moreover as the type of patterns to be scanned almost remains common across application the task also tends to get a bit repetitive. In such a scenario, scanners play a big role is automating the process of searching the vulnerabilities through big numbers of lines of code. <br />
<br />
'''2. Time efficient '''– Scanners are must time efficient than manual reviews. In most cases the scanners have proved to be much faster than manual process of reviewing the source code.<br />
<br />
'''3.Finds all the instances of the vulnerabilities '''- Scanners are very effective in identifying all the instances of a particular vulnerability with their exact location. This is really helpful for larger code base where tracing for flaws in all the files is difficult.<br />
<br />
'''4. Source to sink analysis '''– Most scanners today trace the code and identify the vulnerabilities through source to sink analysis. They identify the inputs to the application and trace them thoroughly throughout the code till they find them to be associated with any insecure code pattern. Such a source to sink analysis helps the developers in understanding the flaws better as they get a complete root cause analysis of the flaw. <br />
<br />
'''5. Exhaustive coverage of vulnerability patterns ''' – Most of the scanners have well-defined set of test cases covering all the well-known vulnerabilities. Thus through the use of scanners we can ensure that the code gets thoroughly checked for all the pre-defined set of flaws. <br />
<br />
'''6. Elaborate reporting format '''– Scanners provide a detailed report on the observed vulnerabilities with exact code snippets, risk rating and complete description of the vulnerabilities. This helps the development teams to easily understand the flaws and implement necessary controls. <br />
<br />
'''Limitations of static code analyzers:'''<br />
<br />
'''1.Business Logic Flaws remain untouched '''– The flaws that are related to application’s logic, transactions, and specific sensitive data remain untouched by the scanners. The security controls that needs to be implemented in the application specific its features and design are often not pointed by the scanners. This stands as a biggest limitation of the static code analyzers. <br />
<br />
'''2. Limited scope '''– Static code analyzers are often designed for specific frameworks or certain set of vulnerable patterns, they fail to address the issues not covered in their search pattern repository. So the scanners often fail in catching up the vulnerabilities of the new versions of the framework that keeps coming up. <br />
<br />
'''3. Custom validations '''- Most of the static analyzers tool miss out the custom validations added in the application while identifying the flaws. These could include blacklist or whitelist validation present in the application before the input sources. It could also mean the customization added by the developers to the existing design frameworks and inbuilt framework based API, the scanners that go by pattern based search usually miss out in understanding such intricate details of the code.<br />
<br />
'''4. Design flaws '''– Design flaws are lessen known issues and static code analyzers often focus more on the code than the design. Mainly if the application design is custom built it becomes challenging for the scanners to trace the code flow.<br />
<br />
'''5. Application specific recommendations '''– Scanners usually provide a generic solution and do not point out application specific code changes. If the solutions are customized as per the design and the feasibility of the application it will be clearer to the developers and require less code change. <br />
<br />
'''Parameters to be considered for commercial scanners:'''<br />
1. Source to sink analysis Capabilities<br />
2. Support for frameworks <br />
3. Ability to understand customized code or validations<br />
4. Coverage of Business logic cases specially the ones related to authorization<br />
5. Option to customize the pattern search</div>Ashish Raohttps://wiki.owasp.org/index.php?title=CRV2_CanStaticAnalyzersDoAll&diff=156392CRV2 CanStaticAnalyzersDoAll2013-08-04T18:58:05Z<p>Ashish Rao: </p>
<hr />
<div>Secure code review is a process of enumerating the flaws in the application. The flaws may exist in the application due to insecure code, design or configuration. Out of which the flaws that arise due to insecure code can be enumerated to a great extent through automated analysis, as most of them are associated with insecure patterns. <br />
<br />
Automated analysis can be carried out through any of the following three options:<br />
<br />
*Static Code analyzers or scanners<br />
*Custom scripts based on some pattern search<br />
*Open source tools<br />
<br />
Though some scripts and some open source tools are efficient enough in finding some insecure code pattern but they often lack the capability of tracing the data flow. This limitation is fulfilled by the use of static code analyzers or the scanners, which identify the insecure code pattern along with source to the sink analysis. <br />
<br />
***With this we come to the next big question i.e. Can scanners i.e. static code analyzers do it all? <br />
<br />
Static code analyzers or the scanners are the most comprehensive options to automate the process of review. There are many static and binary analysis tools that automate most of the secure code analysis. <br />
Some of the advantages of static code scanners are:<br />
<br />
'''1. Reduction in manual efforts '''– Secure code review can be a tedious process of analyzing thousands of lines of code for host of vulnerabilities. Also as the type of patterns to be scanned almost remains common across application the task tends to get a bit repetitive. <br />
In such a scenario, scanners play a big role is automating the process of searching the vulnerabilities through big numbers of lines of code. <br />
<br />
<br />
'''2. Time efficient '''– Scanners are must time efficient than manual reviews. In most cases the scanners have proved to be faster than manual process of reviewing the source code. <br />
<br />
<br />
'''3.Finds all the instances of the vulnerabilities '''- Scanners are very effective in identifying all the instances of a particular vulnerability with exact location. <br />
<br />
'''4. Source to sink analysis '''– Most scanners today trace the code and identify the vulnerabilities source to sink analysis. They identify the inputs to the application and trace them thoroughly throughout the code till they find them associated with some insecure code patterns. This helps the developers in understanding the flaws better, as they get a complete root cause analysis of the flaw. <br />
<br />
'''5. Exhaustive coverage of vulnerability patterns ''' – Most of the scanners have well-defined set of test cases covering all the well-known vulnerabilities. Thus through use of scanners we can ensure that the code gets thoroughly checked for all the pre-defined set of cases. <br />
<br />
'''6. Elaborate reporting format '''– Scanners provide a detailed report on the observed vulnerabilities with exact code snippets, risk rating and completed description of the vulnerabilities. This helps the development teams to easily understand the flaws and implement necessary controls. <br />
<br />
'''Limitations of static code analyzers:'''<br />
<br />
'''1.Business Logic Flaws remain untouched '''– Scanners do not understand the application. The flaws that are related to application’s logic, transactions, and specific sensitive data remain untouched by the scanners. The security controls that need to be implemented specific to the application’s features and design are often not pointed by the scanners. This stands as a biggest limitation of the static code analysers. <br />
<br />
'''2. Limited scope '''– Static code analyzers are often designed for specific frameworks or certain set of vulnerable patterns, they fail to address the issues not covered in their search pattern repository. So the scanners often fail in catching up the vulnerabilities of the new versions of the framework. <br />
<br />
'''3. Custom validations '''- Most of the static analysers tool miss out the custom validations added in the application while identifying the flaws. These could include blacklist or whitelist validation present in the application before the input sources. It could also mean the customization added by the developers to the existing design frameworks and inbuilt framework based API, the scanners that go by pattern based search usually miss out in understanding such intricate details of the code. <br />
<br />
'''4. Design flaws '''– Design flaws are lessen known issues and static code analysers focus more on the code than the design. Mainly if the application design is custom built it becomes challenging for the scanners to trace the code flow and in the event results in false negatives. <br />
<br />
<br />
'''5. Application specific recommendations '''– Scanners usually provide a generic solution and do not point out application specific code changes. If the solutions are customized as per the design and the feasibility of the application it will be clearer to the developers and require less code change. <br />
<br />
'''Parameters to be considered for commercial scanners:'''<br />
1. Source to sink analysis Capabilities<br />
2. Support for frameworks <br />
3. Ability to understand customized code or validations<br />
4. Coverage of Business logic cases specially the ones related to authorization<br />
5. Option to customize the pattern search</div>Ashish Raohttps://wiki.owasp.org/index.php?title=CRV2_CanStaticAnalyzersDoAll&diff=156391CRV2 CanStaticAnalyzersDoAll2013-08-04T18:53:12Z<p>Ashish Rao: Created page with "Secure code review is a process of enumerating the flaws in the application. The flaws may exist in the application due to insecure code, design or configuration. Out of which..."</p>
<hr />
<div>Secure code review is a process of enumerating the flaws in the application. The flaws may exist in the application due to insecure code, design or configuration. Out of which the flaws that arise due to insecure code can be enumerated to a great extent through automated analysis, as most of them are associated with insecure patterns. <br />
Automated analysis can be carried out through any of the following three options:<br />
• Static Code analysers or scanners<br />
• Custom scripts based on some pattern search<br />
• Open source tools<br />
Though some scripts and some open source tools are efficient enough in finding some insecure code pattern but they often lack the capability of tracing the data flow. This limitation is fulfilled by the use of static code analysers or the scanners, which identify the insecure code pattern along with source to the sink analysis. <br />
With this we come to the next big question i.e. Can scanners i.e. static code analysers do it all? <br />
Static code analysers or the scanners are the most comprehensive options to automate the process of review. There are many static and binary analysis tools that automate most of the secure code analysis. <br />
Some of the advantages of static code scanners are:<br />
1. Reduction in manual efforts – Secure code review can be a tedious process of analysing thousands of lines of code for host of vulnerabilities. Also as the type of patterns to be scanned almost remains common across application the task tends to get a bit repetitive. <br />
In such a scenario, scanners play a big role is automating the process of searching the vulnerabilities through big numbers of lines of code. <br />
<br />
2. Time efficient – Scanners are must time efficient than manual reviews. In most cases the scanners have proved to be faster than manual process of reviewing the source code. <br />
<br />
3. Finds all the instances of the vulnerabilities - Scanners are very effective in identifying all the instances of a particular vulnerability with exact location. <br />
<br />
4. Source to sink analysis – Most scanners today trace the code and identify the vulnerabilities source to sink analysis. They identify the inputs to the application and trace them thoroughly throughout the code till they find them associated with some insecure code patterns. This helps the developers in understanding the flaws better, as they get a complete root cause analysis of the flaw. <br />
<br />
5. Exhaustive coverage of vulnerability patterns – Most of the scanners have well-defined set of test cases covering all the well-known vulnerabilities. Thus through use of scanners we can ensure that the code gets thoroughly checked for all the pre-defined set of cases. <br />
<br />
6. Elaborate reporting format – Scanners provide a detailed report on the observed vulnerabilities with exact code snippets, risk rating and completed description of the vulnerabilities. This helps the development teams to easily understand the flaws and implement necessary controls. <br />
<br />
Limitations of static code analysers:<br />
1. Business Logic Flaws remain untouched – Scanners do not understand the application. The flaws that are related to application’s logic, transactions, and specific sensitive data remain untouched by the scanners. The security controls that need to be implemented specific to the application’s features and design are often not pointed by the scanners. This stands as a biggest limitation of the static code analysers. <br />
<br />
2. Limited scope – Static code analysers are often designed for specific frameworks or certain set of vulnerable patterns, they fail to address the issues not covered in their search pattern repository. So the scanners often fail in catching up the vulnerabilities of the new versions of the framework. <br />
<br />
3. Custom validations - Most of the static analysers tool miss out the custom validations added in the application while identifying the flaws. These could include blacklist or whitelist validation present in the application before the input sources. It could also mean the customization added by the developers to the existing design frameworks and inbuilt framework based API, the scanners that go by pattern based search usually miss out in understanding such intricate details of the code. <br />
<br />
4. Design flaws – Design flaws are lessen known issues and static code analysers focus more on the code than the design. Mainly if the application design is custom built it becomes challenging for the scanners to trace the code flow and in the event results in false negatives. <br />
<br />
<br />
5. Application specific recommendations – Scanners usually provide a generic solution and do not point out application specific code changes. If the solutions are customized as per the design and the feasibility of the application it will be clearer to the developers and require less code change. <br />
<br />
Parameters to be considered for commercial scanners:<br />
1. Source to sink analysis Capabilities<br />
2. Support for frameworks <br />
3. Ability to understand customized code or validations<br />
4. Coverage of Business logic cases specially the ones related to authorization<br />
5. Option to customize the pattern search</div>Ashish Raohttps://wiki.owasp.org/index.php?title=CRV2_WhyCodeReview&diff=155428CRV2 WhyCodeReview2013-07-12T19:23:36Z<p>Ashish Rao: Created page with "Security code review aims to identify security flaws in the application related to its features and design along with their exact root causes. With the increasing complexity o..."</p>
<hr />
<div>Security code review aims to identify security flaws in the application related to its features and design along with their exact root causes.<br />
With the increasing complexity of the applications and the advent of new technologies the traditional way of testing may fail to detect all the security flaws present in the applications. Thus, there is a need to understand the code of the application, external components, technologies and configurations to be able to uproot all the flaws in different kinds of applications. Such a deep dive into the application code also helps in determining exact mitigation techniques that can be used to avert the security flaws.<br />
Let’s look in further detail of the benefits of security code reviews. <br />
<br />
*'''Root cause analysis (Source to sink)''' – There are various reasons why security flaws manifest in the application like lack of validation, parameter mishandling etc. During the assessment, the code is thoroughly studied and such flaws are checked. In the process the exact root cause of the flaws are captured. The complete data flow is traced and source to sink analysis is carried out. Source to sink analysis here means to determine what are possible inputs to the application i.e. source, and how are they being processed by it. Sink refers an insecure code pattern like for instance, a dynamic SQL query. So, its analyzing what is the source (input) and the sink (vulnerable code pattern) for any vulnerability. Consider a scenario where the source is a user input. It flows through the different classes/components of the application and finally falls into a concatenated SQL query i.e. a sink, and there is no proper validation being applied to it in the path. In this case the application will be vulnerable to SQL Injection attack, as identified by the source to sink analysis. Such an analysis exactly helps in understanding which vulnerable inputs can lead to a possibility of an exploit in the application.<br />
<br />
*'''Design Analysis''' – Design is an important aspect of security code review. The dynamic testing approach does not involve design analysis, which also serves as it one of the limitations. The design flaws are difficult to uncover and requires knowledge of the entire data flow, input sources, integrations and all the configurations of the application. Thus, the flaws related to mishandling of non-user inputs and external integrations like server to server, which are unlikely to get covered in a dynamic testing approach can be easily determined in a security code review. It covers the end-to-end analysis of the application<br />
<br />
*'''All Instances of the Vulnerabilities''' – Once a flaw is identified the next step of the security code review process is to enumerate its all the possible instances present in the application. Through security code reviews we can uncover insecure patterns present in all the files of the application. Here, all insecure instances includes the list of different the insecure code patterns that lead to a vulnerability and all of their occurrences. For instance, an application can be vulnerable to XSS vulnerability because of use of unvalidated inputs in insecure display methods like scriplets, response.write method etc. at several places. <br />
<br />
*'''Uncommon Security Flaws''' – Security code reviews is very specific to the application being reviewed. It may highlight some flaws that are new or specific to the code implementation of the application like insecure termination of execution flow, synchronization error etc. These flaws can only be uncovered if we understand the application code flow and its logic well. Thus, security code review is not just about scanning the code for set of unknown insecure code patterns. But it also involves understanding the code implementation of the application and enumerating the flaws specific to it. <br />
<br />
<br />
*'''Limitations of Existing Security Controls''' – The application being reviewed might have been designed with some security controls in place like centralized blacklist validation etc. or there could be some inbuilt validation/security controls present in the application platform being used. These security controls must be studied carefully to identify if they are fool-proof. According to the implementation of the control, the nature of attack or any specific attack vector that can be used to bypass it, must be analysed. Enumerating the weakness in the existing security control is another important aspect of the security code reviews. <br />
<br />
*'''Specific Recommendations''' – The security code reviews also helps to come up with mitigation techniques that can best suit the application, instead of a generic one.</div>Ashish Raohttps://wiki.owasp.org/index.php?title=Projects/OWASP_Secure_Application_Design_Project/Releases/Current&diff=153887Projects/OWASP Secure Application Design Project/Releases/Current2013-06-16T11:05:24Z<p>Ashish Rao: </p>
<hr />
<div>=DRAFT ---DESIGN FLAWS=<br />
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.<br />
==Business Logic Decision==<br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. Two such cases are listed below, it is important to look for such scenarios in the application while testing.<br />
#Use of non-editable controls – Applications may use the values of non-editable controls, drop-down menus, hidden fields or query string parameters for business logic processing. If such fields contain values like the type of the user, nature of the request, status of the transaction, etc. the attackers will get a chance to manipulate them and perform unauthorized operations. The application developers must understand that such fields are non-editable only in the context of the proxy tool. The attackers can easily modify their values using a proxy editor tool and try to manipulate business logic.<br />
#Business logic decision based on presence or absence of certain parameters - This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behavior of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. <br />
Thus there exists a hole in such applications where the server side behavior can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
'''Secure Design Recommendation:''' <br />
*The application must not expose such parameters to the users. <br />
*If they are exposed, the application must not rely on request parameters for logical decisions. It must maintain a separate copy of such values at the server side and use the same for business logic processing.<br />
*Apply proper authorization checks on the server side for all transactions, wherever necessary. Do not depend on presence of a user input for such decisions.<br />
<br />
==Business Logic Invocation Technique==<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application.<br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class<br />
<img 1><br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be unused configurations present in the configuration file. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
'''Consider another scenario'''<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class. <br />
<br />
'''What is the flaw?'''<br />
<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
'''Secure Design Recommendation:'''<br />
The applications must ensure to:<br />
*Remove ALL redundant/test/unexposed business logic configurations from the file<br />
*Apply necessary authorization check before processing business logic method<br />
*Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
Understand the business logic invocation technique used in the design of any application. Check if the user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
*Business logic class<br />
*Method names<br />
*View component<br />
<br />
==Data Binding Technique==<br />
<br />
'''Introduction'''<br />
<br />
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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
==Placement of Security Controls==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
==Execution Flow==<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
Some links for reference:<br />
*http://artechtalks.blogspot.in/<br />
*http://packetstormsecurity.com/files/119129/Insecure-Authentication-Control-In-J2EE.html</div>Ashish Raohttps://wiki.owasp.org/index.php?title=Projects/OWASP_Secure_Application_Design_Project/Releases/Current&diff=153886Projects/OWASP Secure Application Design Project/Releases/Current2013-06-16T11:03:08Z<p>Ashish Rao: Created page with "==DESIGN FLAWS== 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 ..."</p>
<hr />
<div>==DESIGN FLAWS== <br />
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.<br />
===Business Logic Decision=== <br />
During testing it is crucial to identify the key parameters related to business logic and understand how application handles them. This section will focus on insecure business logic decisions that are based on such parameters. Two such cases are listed below, it is important to look for such scenarios in the application while testing.<br />
#Use of non-editable controls – Applications may use the values of non-editable controls, drop-down menus, hidden fields or query string parameters for business logic processing. If such fields contain values like the type of the user, nature of the request, status of the transaction, etc. the attackers will get a chance to manipulate them and perform unauthorized operations. The application developers must understand that such fields are non-editable only in the context of the proxy tool. The attackers can easily modify their values using a proxy editor tool and try to manipulate business logic.<br />
#Business logic decision based on presence or absence of certain parameters - This is especially observed in ASP.NET applications where there is provision to make the server side controls hidden/invisible for certain users. However, in most cases it has been observed that if the users add the parameters corresponding to the UI elements that are kept hidden/invisible to them into the request, they are able to change the behavior of the server side logic. <br />
Consider a scenario where only admin user can change password of other users of the system, as a result the field to enter username is only made visible to the admin user. However, if a normal a user tries to add username parameter in the request he/she will be able to trick the server in believing that the request has come from an admin user and try to change password of other users. <br />
Thus there exists a hole in such applications where the server side behavior can be influenced with request parameters. Users can perform unauthorized operations in the application by supplying the values for the inputs fields that are hidden from them.<br />
<br />
'''Secure Design Recommendation:''' <br />
*The application must not expose such parameters to the users. <br />
*If they are exposed, the application must not rely on request parameters for logical decisions. It must maintain a separate copy of such values at the server side and use the same for business logic processing.<br />
*Apply proper authorization checks on the server side for all transactions, wherever necessary. Do not depend on presence of a user input for such decisions.<br />
<br />
===Business Logic Invocation Technique===<br />
<br />
'''Introduction'''<br />
<br />
In most of the design techniques the request parameters or the URL’s serve as sole factors to determine the processing logic. In such a scenario the elements in the request which are used for such identifications may be subject to manipulation attacks to obtain access to restricted resources or pages in the application.<br />
<br />
Consider a design below; here the business logic class is identified based on a configuration file that keeps the mapping of the request URL and the business logic class i.e. action class<br />
<img 1><br />
'''What is the flaw?'''<br />
<br />
A flaw in such a design could be unused configurations present in the configuration file. Such configurations that are not exposed as valid features in the application and could serve as a potential backdoor to it. <br />
An unused configuration present in the configuration file of the application is shown below:<br />
Observe that the “TestAction” has an insecure logic to delete records from the system. This can act as a potential backdoor to the application.<br />
<br />
'''Consider another scenario'''<br />
<br />
In the some designs request parameters are used to identify business logic methods. In the figure shown below a request parameter named “event” is used to identify and invoke the corresponding event handling methods of the business logic/action class. <br />
<br />
'''What is the flaw?'''<br />
<br />
Here, the user can attempt to invoke the methods of the events that are not visible to the user.<br />
<br />
'''Secure Design Recommendation:'''<br />
The applications must ensure to:<br />
*Remove ALL redundant/test/unexposed business logic configurations from the file<br />
*Apply necessary authorization check before processing business logic method<br />
*Maintain a mapping of method/class/view names with the privilege level of the users, wherever applicable and restrict access of the users to restricted URLs/methods/views.<br />
<br />
'''Review Criteria'''<br />
<br />
Understand the business logic invocation technique used in the design of any application. Check if the user inputs are directly (i.e. without any restriction) used to determine any of the following elements (as applicable):<br />
<br />
*Business logic class<br />
*Method names<br />
*View component<br />
<br />
===Data Binding Technique===<br />
<br />
'''Introduction'''<br />
<br />
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. <br />
Consider a sample design given below; observe that the business logic class binds the business object with the request parameters.<br />
<br />
'''What is the flaw?'''<br />
<br />
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.<br />
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. <br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
*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. <br />
*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. <br />
<br />
'''Review Criteria'''<br />
<br />
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.<br />
<br />
===Placement of Security Controls===<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
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. <br />
Most application developers feel “view” is the right place to have the security checks like authentication check etc. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
Consider a MVC based given in the figure below. Observe in the figure that the authentication check is present only in the view pages. <br />
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.<br />
<br />
'''Insecure POST-BACK’s in ASP.NET'''<br />
<br />
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 -[[http://artechtalks.blogspot.in/2013/02/insecure-postback-based-authentication.html]]<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
Check if the placement of the security checks is correct. The security controls like authentication check must be place before processing any request.<br />
<br />
===Execution Flow===<br />
<br />
'''Introduction'''<br />
<br />
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.<br />
<br />
''response.sendRedirect(“home.html”);''<br />
<br />
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.<br />
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.<br />
<br />
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.<br />
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. <br />
<br />
'''What is the flaw?'''<br />
<br />
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. <br />
<br />
'''Note:''' The fact that execution of a servlet or JSP continues even after sendRedirect() method, also applies to Forward method of the RequestDispatcher Class.<br />
However, <jsp:forward> tag is an exception, it is observed that the execution flow stops after the use of <jsp:forward> tag.<br />
<br />
'''Secure Design Recommendation:'''<br />
<br />
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.<br />
<br />
'''Review criteria'''<br />
<br />
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.<br />
<br />
Some links for reference:<br />
*http://artechtalks.blogspot.in/<br />
*http://packetstormsecurity.com/files/119129/Insecure-Authentication-Control-In-J2EE.html</div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=152466OWASP Secure Application Design Project2013-05-29T18:39:28Z<p>Ashish Rao: </p>
<hr />
<div>=INTRODUCTION =<br />
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. <br />
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.<br />
<br />
=UNDERSTANDING THE DESIGN=<br />
'''What is an application design?'''<br />
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. <br />
<br />
'''Why should be review the design?'''<br />
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. <br />
<br />
=METHODOLOGY OF DESIGN REVIEW=<br />
The methodology to be followed for design reviews is explained below:<br />
<br />
[[File:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [[File:Checklist For Design.pdf]].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design.png&diff=152465File:Design.png2013-05-29T18:38:43Z<p>Ashish Rao: uploaded a new version of &quot;File:Design.png&quot;</p>
<hr />
<div></div>Ashish Raohttps://wiki.owasp.org/index.php?title=OWASP_Secure_Application_Design_Project&diff=152464OWASP Secure Application Design Project2013-05-29T18:34:50Z<p>Ashish Rao: </p>
<hr />
<div>=INTRODUCTION =<br />
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. <br />
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.<br />
<br />
=UNDERSTANDING THE DESIGN=<br />
'''What is an application design?'''<br />
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. <br />
<br />
'''Why should be review the design?'''<br />
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. <br />
<br />
=METHODOLOGY OF DESIGN REVIEW=<br />
The methodology to be followed for design reviews is explained below:<br />
[[File:Design.png]]<br />
<br />
=='''Collection of Design Documents'''==<br />
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. <br />
Requirements documents are also needed to understand the objective of the proposed design.<br />
<br />
=='''Design Study'''==<br />
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. <br />
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.<br />
<br />
# Data Flow/Code Layout<br />
# Access control<br />
# Existing/Built-in Security controls<br />
# Entry points of non-user inputs<br />
# Integrations with external services<br />
# Location of configurations file and data sources<br />
# Add-ons and customization present (in case of built-in design framework)<br />
<br />
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.<br />
<br />
=='''Design Analysis'''==<br />
After understanding the design the next phase is to analyse the threats for the design. This phase involves “threat modelling” the design.<br />
<br />
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. <br />
The analysis can be done broadly on the basis of 2 important criteria:<br />
<br />
'''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. <br />
<br />
'''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. <br />
<br />
Similar instances are listed below to illustrate the points that should be broadly considered while analysing different design areas:<br />
# Data Flow -<br />
## Are user inputs used to directly reference a business logic class/function<br />
## Is there a data binding flaw?<br />
## Does it expose any backdoor parameter to invoke business logic?<br />
## Is the execution flow of the application correct?<br />
# Authentication and access control - <br />
## Does the design implement access control for all the files?<br />
## Does it handle session securely?<br />
## Is there SSO, does it leave any backdoor?<br />
# Existing/built-in Security Controls - <br />
## Weakness in any existing security control<br />
## Is the placement of the security controls correct?<br />
# Architecture – <br />
## Is there validation for all input sources?<br />
## Is the connection to external servers secure?<br />
#Configuration/code files and datastores - <br />
## Are sensitive data present in configuration files?<br />
## Does it support any insecure data source?<br />
<br />
A detailed checklist is available here - [[File:Checklist For Design.pdf]].<br />
<br />
At the end of this activity we get a list of threats or insecure areas applicable to the design. <br />
<br />
=='''Propose Security Requirements'''==<br />
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. <br />
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. <br />
<br />
=='''Recommend Design Changes'''==<br />
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:<br />
# Elaborate validation strategy with respect to:<br />
##Identifying right application component like servlet filters, interceptors, validator classes etc.<br />
##Placement of check<br />
## Validation mechanism<br />
## Use of 3rd party security API’s or inbuilt design features of the frameworks<br />
# Encryption techniques<br />
# Design Patterns<br />
And so on depending on the control to be built in the design. <br />
<br />
=='''Discussion with the design team'''==<br />
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. <br />
<br />
=='''Design Finalization'''==<br />
The final design incorporated by the development teams must be reviewed again and finalized for further development process.<br />
<br />
=Project About=<br />
{{:Projects/OWASP_Secure_Application_Design_Project}} <br />
<br />
[[Category:OWASP Project]]</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Checklist_For_Design.pdf&diff=152463File:Checklist For Design.pdf2013-05-29T18:27:30Z<p>Ashish Rao: uploaded a new version of &quot;File:Checklist For Design.pdf&quot;</p>
<hr />
<div>Covered in Ashish Rao's presentation at AppSec APAC 2013 - Design Secure Web Applications</div>Ashish Raohttps://wiki.owasp.org/index.php?title=File:Design.png&diff=152460File:Design.png2013-05-29T18:20:02Z<p>Ashish Rao: </p>
<hr />
<div></div>Ashish Rao