Difference between revisions of "OWASP Proactive Controls"

It is not easy to build a secure, low-risk or risk-managed web application. Firewalls, “policy” and other traditional information security measures serve as either an incomplete or useless measure in the pursuit of web application security.

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. It’s also very rare when organizations provide developers with prescriptive requirements that guide them down the path of secure software. When it’s 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.

This document is neither scientific nor complete. In fact it’s a bit misguided. 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-sheet series team whose content has been pulled from liberally for this document.

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

1) Secure Requirements

- Core requirements for any project (technical) - Business logic requirements (project specific)

2) Secure Architecture and Design

- When to use request, session or database for data flow

3) Leverage secure coding frameworks and libraries

- Shiro - ESAPI

4) Identity and Authentication

- Password Storage - Forgot Password Workflow - Multi-Factor AuthN

5) Access Control

- Permission based access control - Limits of RBAC

6) Query Parametrization

There have been many high visibility attacks against web applications that can be traced back to a SQL injection attack. SQL Injection is perhaps one of the most dangerous web application risk due to the fact that SQL Injection is both easy to exploit and can deliver an impact to your application that is quite devastating. Businesses, governments and social network sites have all fallen victim to this attack making it a fairly universal problem. Various statistical studies has shown that between 7 to 10% of all websites still contain SQL Injection. While many cite the problem of SQL injection as a vendor issue, process issues or issue that is impossible to fix, ultimately it’s a developer programming issue that can be quite simple to fix in comparison to other security issues that we will discuss below.

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 to stop SQL Injection is with the programming technique known as Query Parameterization.

Here is an example of query 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);

7) Validation

- Whitelist Validation (struggles with internationalization) - URL validation (as part of redirect features) - HTML Validation (as part of untrusted content from features like TinyMCE)

8) Encoding

- Output encoding for XSS - Query Parameterization - Other encodings for LDAP, XML construction and OS Command injection resistance

9) Data Protection

- At rest and in transit - Secure number generation - Certificate pinning - Proper use of AES (CBC/IV Management)

10) Logging, Error Handling and Intrusion Detection

- Information leakage avoidance - Attack detection - Proper error handling workflow

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

We are currently seeking volunteers who will help developing stub/empty articles listed bellow and bring it up to a production level of quality. Join us now to take part in this historic effort, just drop a line to Jim Manico and Andrew van der Stock!

What's In It?

Original list from Andrew

1. Security Architecture (including incorporating agile ideas)
2. Use a (more) secure development frameworks and leverage enterprise frameworks (UAG, etc)
3. Input validation
4. Output Encoding
5. Identity: Authentication and Session Management
6. Access Control (service / controller, data, URL, function / CSRF, presentation, etc)
7. Data Protection (Data at rest, including in cloud)
8. Audit, Logging and Error Handling
9. Secure Configuration
10. Secure Communications (Data in transit)

Suggested changes by Jim

1. Identity: Authentication and Session Management (same as you)
2. Access Control: (service / controller, data, URL, function / CSRF, presentation, etc) (same as you)
3. Query Parametrization: (this is not encoding or validation, but is essentially a per-compiled query plan into tabular data)
4. Input validation (same)
5. Output Encoding (same)
6. Data Protection: (Data at rest, including in cloud, data in transport)
7. Leverage secure development frameworks and libraries (Shiro, ESAPI, etc)
8. Secure Requirements
9. Secure Design and Architecture
10. Audit, Logging, Error handling and Intrusion Detection