OWASP - User contributions [en]

SSL Best Practices

2008-08-12T16:21:08Z

Joern.zaefferer:

== Status ==
Draft

==What is SSL==

SSL is the abbreviation of Secured Socket Layer. It is a protocol enabling to settle a secured communication between two hosts. The origin host is viewed as an SSL client and the destination host as an SSL server.

SSL has also been normalised as the TLS (Transport Layer Security) protocol.

'''SSL is used on top of a transport level protocol''' like HTTP or FTP in order to secure it.

SSL enables :
* authentication of the destination host for the origin host or mutual authentication of both the origin and the destination hosts
* data confidentiality through encryption
* data integrity checking through hashing.

SSL relies on two types of encryption :
* public key encryption in the initiation phase, where authentication takes place
* secret key encryption when a session has been established and data is sent between two peers which trust each other.

'''SSL only secures the communication between two endpoints''' : in the origin and destination points, data is in clear text, unless it is encrypted by another means, at the application level.

==How SSL is implemented in J2EE==
==HTTPS best practices in general==
==HTTPS best practices in J2EE==
==Examples with Tomcat==
==Examples with JBoss==

==Examples with Jetty==

See [http://docs.codehaus.org/display/JETTY/How+to+configure+SSL How to configure SSL] for Jetty

[[Category:OWASP Java Project]]

Preventing SQL Injection in Java

2008-08-12T16:08:10Z

Joern.zaefferer: /* Parameterizied Queries */ spelling

==Status==
Released 14/1/2008

==Overview==
As the name implies, SQL injection vulnerabilities allow an attacker to inject (or execute) SQL commands within an application. It is one of the most wide spread and dangerous application vulnerability. The CLASP project provides a good overview of [[SQL injection]].

==Example of SQL injection==
The following Java servlet code, used to perform a login function, illustrates the vulnerability by accepting user input without performing adequate input validation or escaping meta-characters:
conn = pool.getConnection( );
String sql = "select * from user where username='" + username +"' and password='" + password + "'";
stmt = conn.createStatement();
rs = stmt.executeQuery(sql);
if (rs.next()) {
loggedIn = true;
out.println("Successfully logged in");
} else {
out.println("Username and/or password not recognized");
}
It is possible for attackers to provide a username containing SQL meta-characters that subvert the intended function of the SQL statement. For example, by providing a username of:
admin' OR '1'='1
and a blank password, the generated SQL statement becomes:
select * from user where username='admin' OR '1'='1' and password=' '
This allows an attacker to log in to the site without supplying a password, since the ‘OR’ expression is always true. Using the same technique attackers can inject other SQL commands which could extract, modify or delete data within the database.

==Attack techniques==
For more information on SQL injection attacks see:
* http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
* http://www.nextgenss.com/papers/advanced_sql_injection.pdf
* http://www.appsecinc.com/presentations/Manipulating_SQL_Server_Using_SQL_Injection.pdf

==Defence Strategy==
To prevent SQL injection:
* All queries should be parametrized.
* All dynamic data should be explicitly bound to parametrized queries.
* String concatenation should never be used to create dynamic SQL.

==Parameterized Queries==
All data access techniques provide some means for escaping SQL meta-characters automatically. The following sections detail how to perform input validation and meta-character escaping using popular data access technologies.

===Prepared Statements===
Variables passed as arguments to prepared statements will automatically be escaped by the JDBC driver. 
Example: ps.1 
String selectStatement = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(selectStatement);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

Although Prepared Statements helps in defending against SQL Injection, there are possibilities of SQL Injection attacks through inappropriate usage of Prepared Statements. The example below explains such a scenario where the input variables are passed directly into the Prepared Statement and thereby paving way for SQL Injection attacks. 
Example: ps.2 
<pre>
String strUserName = request.getParameter("Txt_UserName");
PreparedStatement prepStmt = con.prepareStatement("SELECT * FROM user WHERE userId = '+strUserName+'");
</pre>

===Stored Procedures===

TODO

===Hibernate===
According to [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc this forum thread] hibernate uses prepared statements, so it is protected from direct sql injection, but it could still be vulnerable to [http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection injecting HQL statements].

==Variable Binding==

It is critical to use Bind Variables as mentioned in the example ps.1 above. Usage of PreparedStatement with Bind variables defends SQL Injection attacks and improves the performance.

==Dynamic Queries via String Concatenation==

The important thing to remember is to never construct SQL statements using string concatenation of unchecked input values. Creating of dynamic queries via the java.sql.Statement class leads to SQL Injection.

== References ==
*[1] [http://research.corsaire.com/whitepapers/060116-a-modular-approach-to-data-validation.pdf A Modular Approach to Data Validation]
*[2] [http://forum.hibernate.org/viewtopic.php?t=960817&start=0&postdays=0&postorder=asc&highlight= Topic: does Hibernate guard against SQL injection?]

[[Category:OWASP Java Project]]

OWASP Java Table of Contents

2008-08-12T16:02:50Z

Joern.zaefferer: /* Noteworthy Frameworks */ added Wicket

Key:
* xx%: Progress status of the paragraph
* Review: The paragraph needs a review
* TD: Paragraph to be assigned

==[[J2EE Security for Architects]]==
Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.
===Design considerations===
* Architectural considerations (0%, TD)
** EJB Middle tier (0%, TD)
** Web Services Middle tier (0%, TD)
** Spring Middle tier (0%, TD)

==[[J2EE Security for Developers]]==
=== Noteworthy Frameworks ===
Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.

(0%, Seeking Volunteers)
* [[Struts]] (0% Jon Forck)
* Turbine
* [[Java Server Faces]] (Sam Reghenzi - 90%, Finalising content)
* Tapestry
* Webwork
* Cocoon
* Tiles
* SiteMesh
* Spring (0%, Adrian San Juan, TD)
* [[Wicket]]

===[[Java Security Basics]]===
Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.
* Class Loading (0%, Philippe Clairet)
* Bytecode verifier (0%, Philippe Clairet)
* The Security Manager and security.policy file (0%, John Wilander, Philippe Clairet)

===Input Validation Overview ===
Input validation is perhaps the most important category of application security. Any data entering a software system must be verified to contain safe data that is not mounting a SQL Injection, XSS, CSRF or other form of attack. This is done primarily through the use of regular expressions. It's crucial not to hard-code input validation routines. Regular expressions should contained within a configuration file that can easily updated by an InfoSec professional and not require a programmers intervention or deployment of new application code. Application security needs change over time as new attack vectors are discovered. Application administers need to be able to react to these changes as quickly as possible.

===Input Validation ===
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...) (0%, TD)
* [[How to add validation logic to HttpServletRequest]] (100%, Jeff Williams, Complete)
* [[How to perform HTML entity encoding in Java]] (100%, Jeff Williams, Complete)

==== [[Preventing SQL Injection in Java]] ====
* Overview
* Prevention (60%, Stephen de Vries, Review)
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis (60%, Rohyt Belani, Review)
** Spring JDBC
** EJB 3.0
** JDO

==== [[Preventing LDAP Injection in Java]] ====
* Overview (100%, Stephen de Vries, Complete)
* Prevention (100%, Stephen de Vries, Complete)

==== [[XPATH Injection]] ====
As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.
* Overview (0%, TD)
* Prevention (0%, TD)

==== [[Miscellaneous Injection Attacks]] ====
* HTTP Response splitting (0%, TD)
* Command injection - Runtime.getRuntime().exec() (0%, TD)
* Regular Expression (regex) Injections (20%)

''' Status '''
In progress

=== Authentication===
* [[Storing credentials]] - (20%, Adrian San Juan, Review)
* [[Hashing Java|Hashing]] - (100%, Michel Prunet, Review)
* [[SSL Best Practices]] - (20%, Philippe Curmin, Review)
* [[Using JCaptcha]] - (100%, Dave Ferguson, Review)
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]] - (100%, Dave Ferguson, Completed)
* [[JAAS Timed Login Module]] - (100%, Stephen de Vries, Review)
* [[JAAS Tomcat Login Module]] - (100%, Stephen de Vries, Review)
* [[Password length & complexity]] - (100%, Adrian San Juan, Review)

===Session Management ===
The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples.
* Logout (0%, TD)
* Session Timeout (0%, TD)
* Absolute Timeout (0%, TD)
* [[Session Fixation in Java]] (100%, Rohyt Belani, Review)
* Terminating sessions (0%, TD)
** Terminating sessions when the browser window is closed

===Authorization===
* [[Declarative v/s Programmatic]] (10%, TD)
* EJB Authorization (0%, TD)
* Acegi (0%, TD)
* JACC (0%, TD)
* Check horizontal privilege (0%, TD)

=== Encryption===
* [http://www.owasp.org/index.php/Using_the_Java_Cryptographic_Extensions JCE] (100%, Joe Prasanna Kumar - To be reviewed)
* Storing db secrets (0%, TD)
* Encrypting JDBC connections (0%, TD)
* [http://www.owasp.org/index.php/Using_the_Java_Secure_Socket_Extensions JSSE] (100%, Joe Prasanna Kumar - To be reviewed)
* [http://www.owasp.org/index.php/Digital_Signature_Implementation_in_Java Digital Signatures in Java (100%, Joe Prasanna Kumar - To be reviewed)

=== Error Handling & Logging===
* Logging - why log? what to log? log4j, etc. (0%, TD)
* Exception handling techniques (0%, TD)
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks (50%, TD)
** Servlet spec - web.xml [[Securing tomcat]] (100%, Darren Edmonds, Completed)
** JSP errorPage (0%, TD)
* Web application forensics (0%, TD)

=== Web Services Security ===
* SAML (0%, TD)
* (X)WS-Security (0%, TD)
* SunJWSDP (0%, TD)
* WSS4J (0%, Eelco Klaver)
* XML Signature (JSR 105) (0%, TD)
* XML Encryption (JSR 106) (0%, TD)

=== Code Analysis Tools ===
The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.
* Introduction (0%, TD)
* [[:Category:OWASP LAPSE Project]] (100%, Review)
* FindBugs (0%, TD)
** Creating custom rules
* PMD (0%, TD)
** Creating custom rules
* JLint (0%, TD)
* Jmetrics (0%, TD)

== [[J2EE Security For Deployers]] ==
Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.
=== Securing Popular J2EE Servers ===
* [[Securing tomcat|Securing Tomcat]] - (100%, Darren Edmonds, Completed)
* Securing JBoss (0%, TD)
* Securing WebLogic (0%, TD)
* Securing WebSphere (0%, TD)
* Others...

=== Defining a Java Security Policy ===
Practical information on creating a Java security policies for J2EE servers.
* PolicyTool - JChains already provides this functionality, one policy tool is enough.
* jChains (www.jchains.org) - (0%, TD)

=== Protecting Binaries ===
* Bytecode manipulation tools and techniques (0%, TD)
* [[Bytecode obfuscation]] (100%, Pierre Parrend, Released)
* Convert bytecode to native machine code (0%, TD)
* [[Protecting code archives with digital signatures]] (100%, Pierre Parrend, Released)
* [[Signing jar files with jarsigner]] (100%, Pierre Parrend, Released)

==[[J2EE Security for Security Analysts and Testers]]==
* Using Eclipse to verify Java applications (0%, TD)
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - (0%, TD)
* Decompiling Java bytecode (0%, TD)

== [[Java Security Resources]] (ongoing)==

[[Category:OWASP Java Project]]

Talk:Maintenance

2008-08-12T15:49:28Z

Joern.zaefferer: New page: About Update Notifications: Isn't this about web application security? Since when do web apps need the user to manually update?

About Update Notifications: Isn't this about web application security? Since when do web apps need the user to manually update?

Guide to Cryptography

2008-08-12T14:52:37Z

Joern.zaefferer: /* Asymmetric Cryptography (also called Public/Private Key Cryptography) */ grammar

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure that cryptography is safely used to protect the confidentiality and integrity of sensitive user data

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS5.18 – Cryptographic key management

==Description ==

Initially confined to the realms of academia and the military, cryptography has become ubiquitous thanks to the Internet. Common every day uses of cryptography include mobile phones, passwords, SSL, smart cards, and DVDs. Cryptography has permeated everyday life, and is heavily used by many web applications.

Cryptography (or crypto) is one of the more advanced topics of information security, and one whose understanding requires the most schooling and experience. It is difficult to get right because there are many approaches to encryption, each with advantages and disadvantages that need to be thoroughly understood by web solution architects and developers. In addition, serious cryptography research is typically based in advanced mathematics and number theory, providing a serious barrier to entry.

The proper and accurate implementation of cryptography is extremely critical to its efficacy. A small mistake in configuration or coding will result in removing a large degree of the protection it affords and rending the crypto implementation useless against serious attacks.

A good understanding of crypto is required to be able to discern between solid products and snake oil. The inherent complexity of crypto makes it easy to fall for fantastic claims from vendors about their product. Typically, these are “a breakthrough in cryptography” or “unbreakable” or provide "military grade" security. If a vendor says "trust us, we have had experts look at this,” chances are they weren't experts!

==Cryptographic Functions ==

Cryptographic systems can provide one or more of the following four services. It is important to distinguish between these, as some algorithms are more suited to particular tasks, but not to others.

When analyzing your requirements and risks, you need to decide which of these four functions should be used to protect your data.

===Authentication ===

Using a cryptographic system, we can establish the identity of a remote user (or system). A typical example is the SSL certificate of a web server providing proof to the user that he or she is connected to the correct server.

The identity is not of the user, but of the cryptographic key of the user. Having a less secure key lowers the trust we can place on the identity.

===Non-Repudiation ===

The concept of non-repudiation is particularly important for financial or e-commerce applications. Often, cryptographic tools are required to prove that a unique user has made a transaction request. It must not be possible for the user to refute his or her actions.

For example, a customer may request a transfer of money from her account to be paid to another account. Later, she claims never to have made the request and demands the money be refunded to the account. If we have non-repudiation through cryptography, we can prove – usually through digitally signing the transaction request, that the user authorized the transaction.

===Confidentiality ===

More commonly, the biggest concern will be to keep information private. Cryptographic systems were originally developed to function in this capacity. Whether it be passwords sent during a log on process, or storing confidential medical records in a database, encryption can assure that only users who have access to the appropriate key will get access to the data.

===Integrity ===

We can use cryptography to provide a means to ensure data is not viewed or altered during storage or transmission. Cryptographic hashes for example, can safeguard data by providing a secure checksum.

==Cryptographic Algorithms ==

Various types of cryptographic systems exist that have different strengths and weaknesses. Typically, they are divided into two classes; those that are strong, but slow to run and those that are quick, but less secure. Most often a combination of the two approaches is used (e.g.: SSL), whereby we establish the connection with a secure algorithm, and then if successful, encrypt the actual transmission with the weaker, but much faster algorithm.

===Symmetric Cryptography ===

Symmetric Cryptography is the most traditional form of cryptography. In a symmetric cryptosystem, the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. These algorithms tend to be comparatively fast, but they cannot be used unless the involved parties have already exchanged keys. Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key. In systems involving a number of users who each need to set up independent, secure communication channels symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys.

Common examples of symmetric algorithms are DES, 3DES and AES. The 56-bit keys used in DES are short enough to be easily brute-forced by modern hardware and DES should no longer be used. Triple DES (or 3DES) uses the same algorithm, applied three times with different keys giving it an effective key length of 128 bits. Due to the problems using the DES alrgorithm, the United States National Institute of Standards and Technology (NIST) hosted a selection process for a new algorithm. The winning algorithm was Rijndael and the associated cryptosystem is now known as the Advanced Encryption Standard or AES. For most applications 3DES is acceptably secure at the current time, but for most new applications it is advisable to use AES.

===Asymmetric Cryptography (also called Public/Private Key Cryptography) ===

Asymmetric algorithms use two keys, one to encrypt the data, and either key to decrypt. These inter-dependent keys are generated together. One is labeled the Public key and is distributed freely. The other is labeled the Private Key and must be kept hidden.

Often referred to as Public/Private Key Cryptography, these cryptosystems can provide a number of different functions depending on how they are used.

The most common usage of asymmetric cryptography is to send messages with a guarantee of confidentiality. If User A wanted to send a message to User B, User A would get access to User B’s publicly-available Public Key. The message is then encrypted with this key and sent to User B. Because of the cryptosystem’s property that messages encoded with the Public Key of User B can only be decrypted with User B’s Private Key, only User B can read the message.

Another usage scenario is one where User A wants to send User B a message and wants User B to have a guarantee that the message was sent by User A. In order to accomplish this, User A would encrypt the message with their Private Key. The message can then only be decrypted using User A’s Public Key. This guarantees that User A created the message Because they are then only entity who had access to the Private Key required to create a message that can be decrcrypted by User A’s Public Key. This is essentially a digital signature guaranteeing that the message was created by User A.

A Certificate Authority (CA), whose public certificates are installed with browsers or otherwise commonly available, may also digitally sign public keys or certificates. We can authenticate remote systems or users via a mutual trust of an issuing CA. We trust their ‘root’ certificates, which in turn authenticate the public certificate presented by the server.

PGP and SSL are prime examples of a systems implementing asymmetric cryptography, using RSA or other algorithms.

===Hashes ===

Hash functions take some data of an arbitrary length (and possibly a key or password) and generate a fixed-length hash based on this input. Hash functions used in cryptography have the property that it is easy to calculate the hash, but difficult or impossible to re-generate the original input if only the hash value is known. In addition, hash functions useful for cryptography have the property that it is difficult to craft an initial input such that the hash will match a specific desired value.

MD5 and SHA-1 are common hashing algorithms used today. These algorithms are considered weak (see below) and are likely to be replaced after a process similar to the AES selection. New applications should consider using SHA-256 instead of these weaker algorithms.

===Key Exchange Algorithms ===

Lastly, we have key exchange algorithms (such as Diffie-Hellman for SSL). These allow use to safely exchange encryption keys with an unknown party.

==Algorithm Selection ==

As modern cryptography relies on being computationally expensive to break, specific standards can be set for key sizes that will provide assurance that with today’s technology and understanding, it will take too long to decrypt a message by attempting all possible keys.

Therefore, we need to ensure that both the algorithm and the key size are taken into account when selecting an algorithm.

===How to determine if you are vulnerable ===

Proprietary encryption algorithms are not to be trusted as they typically rely on ‘security through obscurity’ and not sound mathematics. These algorithms should be avoided if possible.

Specific algorithms to avoid:

* MD5 has recently been found less secure than previously thought. While still safe for most applications such as hashes for binaries made available publicly, secure applications should now be migrating away from this algorithm.

* SHA-0 has been conclusively broken. It should no longer be used for any sensitive applications.

* SHA-1 has been reduced in strength and we encourage a migration to SHA-256, which implements a larger key size.

* DES was once the standard crypto algorithm for encryption; a normal desktop machine can now break it. AES is the current preferred symmetric algorithm.

Cryptography is a constantly changing field. As new discoveries in cryptanalysis are made, older algorithms will be found unsafe. In addition, as computing power increases the feasibility of brute force attacks will render other cryptosystems or the use of certain key lengths unsafe. Standard bodies such as NIST should be monitored for future recommendations.

Specific applications, such as banking transaction systems may have specific requirements for algorithms and key sizes.

===How to protect yourself ===

Assuming you have chosen an open, standard algorithm, the following recommendations should be considered when reviewing algorithms:

'''Symmetric:'''

* Key sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems such as large financial transactions

'''Asymmetric:'''

The difficulty of cracking a 2048 bit key compared to a 1024 bit key is far, far, far, more than the twice you might expect. Don’t use excessive key sizes unless you know you need them. Bruce Schneier in 2002 (see the references section) recommended the following key lengths for circa 2005 threats:

* Key sizes of 1280 bits are sufficient for most personal applications

* 1536 bits should be acceptable today for most secure applications

* 2048 bits should be considered for highly protected applications.

'''Hashes:'''

* Hash sizes of 128 bits (standard for SSL) are sufficient for most applications

* Consider 168 or 256 bits for secure systems, as many hash functions are currently being revised (see above).

NIST and other standards bodies will provide up to date guidance on suggested key sizes.

'''Design your application to cope with new hashes and algorithms'''

==Key Storage ==

As highlighted above, crypto relies on keys to assure a user’s identity, provide confidentiality and integrity as well as non-repudiation. It is vital that the keys are adequately protected. Should a key be compromised, it can no longer be trusted.

Any system that has been compromised in any way should have all its cryptographic keys replaced.

===How to determine if you are vulnerable ===

Unless you are using hardware cryptographic devices, your keys will most likely be stored as binary files on the system providing the encryption.

Can you export the private key or certificate from the store?

* Are any private keys or certificate import files (usually in PKCS#12 format) on the file system? Can they be imported without a password?

* Keys are often stored in code. This is a bad idea, as it means you will not be able to easily replace keys should they become compromised.

===How to protect yourself ===

* Cryptographic keys should be protected as much as is possible with file system permissions. They should be read only and only the application or user directly accessing them should have these rights.

* Private keys should be marked as not exportable when generating the certificate signing request.

* Once imported into the key store (CryptoAPI, Certificates snap-in, Java Key Store, etc), the private certificate import file obtained from the certificate provider should be safely destroyed from front-end systems. This file should be safely stored in a safe until required (such as installing or replacing a new front end server)

* Host based intrusion systems should be deployed to monitor access of keys. At the very least, changes in keys should be monitored.

* Applications should log any changes to keys.

* Pass phrases used to protect keys should be stored in physically secure places; in some environments, it may be necessary to split the pass phrase or password into two components such that two people will be required to authorize access to the key. These physical, manual processes should be tightly monitored and controlled.

* Storage of keys within source code or binaries should be avoided. This not only has consequences if developers have access to source code, but key management will be almost impossible.

* In a typical web environment, web servers themselves will need permission to access the key. This has obvious implications that other web processes or malicious code may also have access to the key. In these cases, it is vital to minimize the functionality of the system and application requiring access to the keys.

* For interactive applications, a sufficient safeguard is to use a pass phrase or password to encrypt the key when stored on disk. This requires the user to supply a password on startup, but means the key can safely be stored in cases where other users may have greater file system privileges.

Storage of keys in hardware crypto devices is beyond the scope of this document. If you require this level of security, you should really be consulting with crypto specialists.

==Insecure transmission of secrets ==

In security, we assess the level of trust we have in information. When applied to transmission of sensitive data, we need to ensure that encryption occurs before we transmit the data onto any untrusted network.

In practical terms, this means we should aim to encrypt as close to the source of the data as possible.

===How to determine if you are vulnerable ===

This can be extremely difficult without expert help. We can try to at least eliminate the most common problems:

* The encryption algorithm or protocol needs to be adequate to the task. The above discuss on weak algorithms and weak keys should be a good starting point

* We must ensure that through all paths of the transmission we apply this level of encryption

* Extreme care needs to be taken at the point of encryption and decryption. If your encryption library needs to use temporary files, are these adequately protected?

* Are keys stored securely? Is an unsecured file left behind after it has been encrypted?

===How to protect yourself ===

We have the possibility to encrypt or otherwise protect data at different levels. Choosing the right place for this to occur can involve looking at both security as well as resource requirements.

'''Application''': at this level, the actual application performs the encryption or other crypto function. This is the most desirable, but can place additional strain on resources and create unmanageable complexity. Encryption would be performed typically through an API such as the OpenSSL toolkit (www.openssl.com) or operating system provided crypto functions.

An example would be an S/MIME encrypted email, which is transmitted as encoded text within a standard email. No changes to intermediate email hosts are necessary to transmit the message because we do not require a change to the protocol itself.

'''Protocol''': at this layer, the protocol provides the encryption service. Most commonly, this is seen in HTTPS, using SSL encryption to protect sensitive web traffic. The application no longer needs to implementing secure connectivity. However, this does not mean the application has a free ride. SSL requires careful attention when used for mutual (client-side) authentication, as there are two different session keys, one for each direction. Each should be verified before transmitting sensitive data.

Attackers and penetration testers love SSL to hide malicious requests (such as injection attacks for example). Content scanners are most likely unable to decode the SSL connection, letting it pass to the vulnerable web server.

'''Network''': below the protocol layer, we can use technologies such as Virtual Private Networks (VPN) to protect data. This has many incarnations, the most popular being IPsec (Internet Protocol v6 Security), typically implemented as a protected ‘tunnel’ between two gateway routers. Neither the application nor the protocol needs to be crypto aware – all traffic is encrypted regardless.

Possible issues at this level are computational and bandwidth overheads on network devices.

==Reversible Authentication Tokens ==

Today’s web servers typically deal with large numbers of users. Differentiating between them is often done through cookies or other session identifiers. If these session identifiers use a predictable sequence, an attacker need only generate a value in the sequence in order to present a seemingly valid session token.

This can occur at a number of places; the network level for TCP sequence numbers, or right through to the application layer with cookies used as authenticating tokens.

===How to determine if you are vulnerable ===

Any deterministic sequence generator is likely to be vulnerable.

===How to protect yourself ===

The only way to generate secure authentication tokens is to ensure there is no way to predict their sequence. In other words: true random numbers.

It could be argued that computers can not generate true random numbers, but using new techniques such as reading mouse movements and key strokes to improve entropy has significantly increased the randomness of random number generators. It is critical that you do not try to implement this on your own; use of existing, proven implementations is highly desirable.

Most operating systems include functions to generate random numbers that can be called from almost any programming language.

'''Windows & .NET:''' On Microsoft platforms including .NET, it is recommended to use the inbuilt CryptGenRandom function (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptgenrandom.asp.

'''Unix:''' For all Unix based platforms, OpenSSL is an excellent option (http://www.openssl.org/). It features tools and API functions to generate random numbers. On some platforms, /dev/urandom is a suitable source of pseudo-random entropy.

'''PHP:''' mt_rand() uses a Mersenne Twister, but is nowhere near as good as CryptoAPI’s secure random number generation options, OpenSSL, or /dev/urandom which is available on many Unix variants. mt_rand() has been noted to produce the same number on some platforms – test prior to deployment. '''Do not use rand() as it is very weak.'''

'''Java:''' java.security.SecureRandom within the Java Cryptography Extension (JCE) provides secure random numbers. This should be used in preference to other random number generators.

'''ColdFusion: '''ColdFusion MX 7 leverages the JCE java.security.SecureRandom class of the underlying JVM as its pseudo random number generator (PRNG)'''''.'' '''

==Safe UUID generation ==

UUIDs (such as GUIDs and so on) are only unique if you generate them. This seems relatively straightforward. However, there are many code snippets available that contain existing UUIDS.

===How to determine if you are vulnerable ===

# Determine the source of your existing UUIDS
## Did they come from MSDN?
## Or from a example found on the Internet?
# Use your favorite search engine to find out

===How to protect yourself ===

* Do not cut and paste UUIDs and GUIDs from anything other than the UUIDGEN program or from the UuidCreate() API

* Generate fresh UUIDs or GUIDs for each new program

==Summary ==

Cryptography is one of pillars of information security. Its usage and propagation has exploded due to the Internet and it is now included in most areas computing. Crypto can be used for:

* Remote access such as IPsec VPN

* Certificate based authentication

* Securing confidential or sensitive information

* Obtaining non-repudiation using digital certificates

* ?Online orders and payments

* Email and messaging security such as S/MIME

A web application can implement cryptography at multiple layers: application, application server or runtime (such as .NET), operating system and hardware. Selecting an optimal approach requires a good understanding of application requirements, the areas of risk, and the level of security strength it might require, flexibility, cost, etc.

Although cryptography is not a panacea, the majority of security breaches do not come from brute force computation but from exploiting mistakes in implementation. The strength of a cryptographic system is measured in key length. Using a large key length and then storing the unprotected keys on the same server, eliminates most of the protection benefit gained. Besides the secure storage of keys, another classic mistake is engineering custom cryptographic algorithms (to generate random session ids for example). Many web applications were successfully attacked because the developers thought they could create their crypto functions.

Our recommendation is to use proven products, tools, or packages rather than rolling your own.

==Further Reading ==

* Wu, H., ''Misuse of stream ciphers in Word and Excel''

http://eprint.iacr.org/2005/007.pdf

* Bindview, ''Vulnerability in Windows NT's SYSKEY encryption''

http://www.bindview.com/Services/razor/Advisories/1999/adv_WinNT_syskey.cfm

* Schneier, B. ''Is 1024 bits enough?, ''April 2002 Cryptogram''

''http://www.schneier.com/crypto-gram-0204.html#3

* Schneier, B., Cryptogram,

http://www.counterpane.com/cryptogram.html

* NIST, Replacing SHA-1 with stronger variants: SHA-256 ? 512

http://csrc.nist.gov/CryptoToolkit/tkhash.html

http://csrc.nist.gov/CryptoToolkit/tkencryption.html

* UUIDs are only unique if you generate them:

http://blogs.msdn.com/larryosterman/archive/2005/07/21/441417.aspx

* Cryptographically Secure Random Numbers on Win32:

http://blogs.msdn.com/michael_howard/archive/2005/01/14/353379.aspx

==Cryptography ==

The following section describes the ColdFusion’s cryptography features. ColdFusion MX leverages the Java Cryptography Extension (JCE) of the underlying J2EE platform for cryptography and random number generation. It provides functions for symmetric (or private-key) encryption. While it does not provide native functionality for public-key (asymmetric) encryption, it does use the Java Secure Socket Extension (JSSE) for SSL communication.

'''Pseudo-Random Number Generation'''

ColdFusion provides three functions for random number generation: rand(), randomize(), and randRange(). Function descriptions and syntax:

'''Rand''' – Use to generate a pseudo-random number

''' rand([algorithm])'''

'''Randomize''' – Use to seed the pseudo-random number generator (PRNG) with an integer.

''' randomize(number [, algorithm])'''

'''RandRange''' – Use to generate a pseudo-random integer within the range of the specified numbers

''' randrange(number1, number2 [, algorithm])'''

The following values are the allowed algorithm parameters''' ''':

CFMX_COMPAT: (default) – Invokes java.util.rand

SHA1PRNG: (recommended) – Invokes java.security.SecureRandom using the Sun Java SHA-1 PRNG algorithm.

IBMSecureRandom: IBM WebSphere’s JVM does not support the SHA1PRNG algorithm.

'''Symmetric Encryption'''

ColdFusion MX 7 provides six encryption functions: decrypt(), decryptBinary(), encrypt(), encryptBinary(), generateSecretKey(), and hash(). Function descriptions and syntax:

'''Decrypt''' – Use to decrypt encrypted strings with specified key, algorithm, encoding, initialization vector or salt, and iterations

''' decrypt(encrypted_string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''DecryptBinary''' – Use to decrypt encrypted binary data with specified key, algorithm, initialization vector or salt, and iterations

''' decryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''Encrypt''' – Use to encrypt string using specific algorithm, encoding, initialization vector or salt, and iterations

''' encrypt(string, key[, algorithm[, encoding[, IVorSalt[, iterations]]]]))'''

'''EncryptBinary''' – Use to encrypt binary data with specified key, algorithm, initialization vector or salt, and iterations

''' encryptBinary(bytes, key[, algorithm[, IVorSalt[, iterations]]])'''

'''GenerateSecretKey''' – Use to generate a secure key using the specified algorithm for the encrypt and encryptBinary functions

''' generateSecretKey(algorithm)'''

'''Hash '''– Use for one-way conversion of a variable-length string to fixed-length string using the specified algorithm and encoding

''' hash(string[, algorithm[, encoding]] )'''

ColdFusion offers the following default algorithms for these functions''' ''':

CFMX_COMPAT: the algorithm used in ColdFusion MX and prior releases. This algorithm is the least secure option (default).

AES: the Advanced Encryption Standard specified by the National Institute of Standards and Technology (NIST) FIPS-197. (recommended)

BLOWFISH: the Blowfish algorithm defined by Bruce Schneier.

DES: the Data Encryption Standard algorithm defined by NIST FIPS-46-3.

DESEDE: the "Triple DES" algorithm defined by NIST FIPS-46-3.

PBEWithMD5AndDES: A password-based version of the DES algorithm which uses a MD5 hash of the specified password as the encryption key

PBEWithMD5AndTripleDES: A password-based version of the DESEDE algorithm which uses a MD5 hash of the specified password as the encryption key

The following algorithms are provided by default for the hash() function. Note, SHA algorithms used in ColdFusion are NIST FIPS-180-2 compliant''' ''':

CFMX_COMPAT: Generates a MD5 hash string identical to that generated by ColdFusion MX and ColdFusion MX 6.1 (default).

MD5: Generates a 128-bit digest.

SHA: Generates a 160-bit digest. (SHA-1)

SHA-256: Generates a 256-bit digest

SHA-384: Generates a 384-bit digest

SHA-512: Generates a 512-bit digest

'''Pluggable Encryption'''

ColdFusion MX 7 introduced pluggable encryption for CFML. The JCE allows developers to specify multiple cryptographic service providers. ColdFusion can leverage the algorithms, feedback modes, and padding methods of third-party Java security providers to strengthen its cryptography functions. For example, ColdFusion can leverage the Bouncy Castle ('''http://www.bouncycastle.org/''') crypto package and use the SHA-224 algorithm for the hash() function or the Serpent block encryption for the encrypt() function.

See Macromedia’s Strong Encryption in ColdFusion MX 7 technote for information on installing additional security providers for ColdFusion at http://www.macromedia.com/go/e546373d.

'''SSL'''

ColdFusion does not provide tags and functions for public-key encryption, but it can communicate over SSL. ColdFusion leverages the Sun JSSE to communicate over SSL with web and LDAP (lightweight directory access protocol) servers. ColdFusion uses the Java certificate database (e.g. jre_root/lib/security/cacerts) to store server certificates. It compares presented certificate of remote systems to those stored in the database. It also grabs the host system’s certificate from this database and uses it to present to remote systems to initiate the SSL handshake. Certificate information is then exposed as CGI variables.

'''''Best Practices'''''

Enable /dev/urandom for higher entropy for random number generation

Call the randomize function before calling rand() or randRange() to seed the random number generator

DO NOT use the CFMX_COMPAT algorithms. Upgrade your application to use stronger cryptographic ciphers.

Use AES or higher for symmetric encryption

Use SHA-256 or higher for the hash function

Use a salt (or random string) for password generation with the hash function

Always use generateSecretKey() to generate keys of the appropriate length for Block Encryption algorithms unless a customized key is required

Use separate key databases to store remote server certificates separately from the ColdFusion server’s certificate

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Encryption]]

Error Handling, Auditing and Logging

2008-08-12T12:44:52Z

Joern.zaefferer: /* Error Handling */ spelling/grammar

[[Guide Table of Contents]]__TOC__

==Objective ==

Many industries are required by legal and regulatory requirements to be:

* Auditable – all activities that affect user state or balances are formally tracked

* Traceable – it’s possible to determine where an activity occurs in all tiers of the application

* High integrity – logs cannot be overwritten or tampered by local or remote users

Well-written applications will dual-purpose logs and activity traces for audit and monitoring, and make it easy to track a transaction without excessive effort or access to the system. They should possess the ability to easily track or identify potential fraud or anomalies end-to-end.

==Environments Affected ==

All.

==Relevant COBIT Topics ==

DS11 – Manage Data – All sections should be reviewed, but in particular:

DS11.4 Source data error handling

DS11.8 Data input error handling

==Description ==

Error handling, debug messages, auditing and logging are different aspects of the same topic: how to track events within an application:

==Best practices ==

* Fail safe – do not fail open

* Dual purpose logs

* Audit logs are legally protected – protect them

* Reports and search logs using a read-only copy or complete replica

==Error Handling ==

Error handling takes two forms: structured exception handling and functional error checking. Structured exception handling is always preferred as it is easier to cover 100% of code. Functional languages, such as PHP 4, that do not have exceptions are very hard to cover 100% of all errors. Code that covers 100% of errors is extraordinarily verbose and difficult to read, and can contain subtle bugs and errors in the error handling code itself.

Motivated attackers like to see error messages as they might leak information that leads to further attacks, or may leak privacy related information. Web application error handling is rarely robust enough to survive a penetration test.

Applications should always fail safe. If an application fails to an unknown state, it is likely that an attacker may be able to exploit this indeterminate state to access unauthorized functionality, or worse create, modify or destroy data.

===Fail safe ===

* Inspect the application’s fatal error handler.

* Does it fail safe? If so, how?

* Is the fatal error handler called frequently enough?

* What happens to in-flight transactions and ephemeral data?

===Debug errors ===

* Does production code contain debug error handlers or messages?

* If the language is a scripting language without effective pre-processing or compilation, can the debug flag be turned on in the browser?

* Do the debug messages leak privacy related information, or information that may lead to further successful attack?

===Exception handling ===

* Does the code use structured exception handlers (try {} catch {} etc) or function-based error handling?

* If the code uses function-based error handling, does it check every return value and handle the error appropriately?

* Would fuzz injection against the average interface fail?

===Functional return values ===

Many languages indicate an error condition by return value. E.g.:

''$query = mysql_query(“SELECT * FROM table WHERE id=4”, $conn);''

''if ( $query === false ) {''

'' // error''

''} ''

* Are all functional errors checked? If not, what can go wrong?

==Detailed error messages ==

Detailed error messages provide attackers with a mountain of useful information.

===How to determine if you are vulnerable ===

* Are detailed error messages turned on?

* Do the detailed error messages leak information that may be used to stage a further attack, or leak privacy related information?

* Does the browser cache the error message?

===How to protect yourself ===

Ensure that your application has a “safe mode” which it can return if something truly unexpected occurs. If all else fails, log the user out and close the browser window

Production code should not be capable of producing debug messages. If it does, debug mode should be triggered by editing a file or configuration option on the server. In particular, debug should not enabled by an option in the application itself

If the framework or language has a structured exception handler (ie try {} catch {}), it should be used in preference to functional error handling

If the application uses functional error handling, its use must be comprehensive and thorough

Detailed error messages, such as stack traces or leaking privacy related information, should never be presented to the user. Instead a generic error message should be used. This includes HTTP status response codes (ie 404 or 500 Internal Server error).

==Logging ==

===Where to log to? ===

Logs should be written so that the log file attributes are such that only new information can be written (older records cannot be rewritten or deleted). For added security, logs should also be written to a write once / read many device such as a CD-R.

Copies of log files should be made at regular intervals depending on volume and size (daily, weekly, monthly, etc.). .). A common naming convention should be adopted with regards to logs, making them easier to index. Verification that logging is still actively working is overlooked surprisingly often, and can be accomplished via a simple cron job!

Make sure data is not overwritten.

Log files should be copied and moved to permanent storage and incorporated into the organization's overall backup strategy.

Log files and media should be deleted and disposed of properly and incorporated into an organization's shredding or secure media disposal plan. Reports should be generated on a regular basis, including error reporting and anomaly detection trending.

Be sure to keep logs safe and confidential even when backed up.

===Handling ===

Logs can be fed into real time intrusion detection and performance and system monitoring tools. All logging components should be synced with a timeserver so that all logging can be consolidated effectively without latency errors. This time server should be hardened and should not provide any other services to the network.

No manipulation, no deletion while analyzing.

===General Debugging ===

Logs are useful in reconstructing events after a problem has occurred, security related or not. Event reconstruction can allow a security administrator to determine the full extent of an intruder's activities and expedite the recovery process.

===Forensics evidence ===

Logs may in some cases be needed in legal proceedings to prove wrongdoing. In this case, the actual handling of the log data is crucial.

===Attack detection ===

Logs are often the only record that suspicious behavior is taking place: Therefore logs can sometimes be fed real-time directly into intrusion detection systems.

===Quality of service ===

Repetitive polls can be protocol led so that network outages or server shutdowns get protocolled and the behavior can either be analyzed later on or a responsible person can take immediate actions.

===Proof of validity ===

Application developers sometimes write logs to prove to customers that their applications are behaving as expected.

* Required by law or corporate policies

* Logs can provide individual accountability in the web application system universe by tracking a user's actions.

It can be corporate policy or local law to be required to (as example) save header information of all application transactions. These logs must then be kept safe and confidential for six months before they can be deleted.

The points from above show all different motivations and result in different requirements and strategies. This means, that before we can implement a logging mechanism into an application or system, we have to know the requirements and their later usage. If we fail in doing so this can lead to unintentional results.

Failure to enable or design the proper event logging mechanisms in the web application may undermine an organization's ability to detect unauthorized access attempts, and the extent to which these attempts may or may not have succeeded. We will look into the most common attack methods, design and implementation errors as well as the mitigation strategies later on in this chapter.

There is another reason why the logging mechanism must be planned before implementation. In some countries, laws define what kind of personal information is allowed to be not only logged but also analyzed. For example, in Switzerland, companies are not allowed to log personal information of their employees (like what they do on the internet or what they write in their emails). So if a company wants to log a workers surfing habits, the corporation needs to inform her of their plans in advance.

This leads to the requirement of having anonymized logs or de-personalized logs with the ability to re-personalized them later on if need be. If an unauthorized person has access to (legally) personalized logs, the corporation is acting unlawful again. So there can be a few (not only) legal traps that must be kept in mind.

===Logging types ===

Logs can contain different kinds of data. The selection of the data used is normally affected by the motivation leading to the logging. This section contains information about the different types of logging information and the reasons why we could want to log them.

In general, the logging features include appropriate debugging information’s such as time of event, initiating process or owner of process, and a detailed description of the event. The following are types of system events that can be logged in an application. It depends on the particular application or system and the needs to decide which of these will be used in the logs:

* Reading of data file access and what kind of data is read. This not only allows to see if data was read but also by whom and when.

* Writing of data logs also where and with what mode (append, replace) data was written. This can be used to see if data was overwritten or if a program is writing at all.

* Modification of any data characteristics, including access control permissions or labels, location in database or file system, or data ownership. Administrators can detect if their configurations were changed.

* Administrative functions and changes in configuration regardless of overlap (account management actions, viewing any user's data, enabling or disabling logging, etc.)

* Miscellaneous debugging information that can be enabled or disabled on the fly.

* All authorization attempts (include time) like success/failure, resource or function being authorized, and the user requesting authorization. We can detect password guessing with these logs. These kinds of logs can be fed into an Intrusion Detection system that will detect anomalies.

* Deletion of any data (object). Sometimes applications are required to have some sort of versioning in which the deletion process can be cancelled.

* Network communications (bind, connect, accept, etc.). With this information an Intrusion Detection system can detect port scanning and brute force attacks.

* All authentication events (logging in, logging out, failed logins, etc.) that allow to detect brute force and guessing attacks too.

==Noise ==

Intentionally invoking security errors to fill an error log with entries (noise) that hide the incriminating evidence of a successful intrusion. When the administrator or log parser application reviews the logs, there is every chance that they will summarize the volume of log entries as a denial of service attempt rather than identifying the 'needle in the haystack'.

===How to protect yourself ===

This is difficult since applications usually offer an unimpeded route to functions capable of generating log events. If you can deploy an intelligent device or application component that can shun an attacker after repeated attempts, then that would be beneficial. Failing that, an error log audit tool that can reduce the bulk of the noise, based on repetition of events or originating from the same source for example. It is also useful if the log viewer can display the events in order of severity level, rather than just time based.

==Cover Tracks ==

The top prize in logging mechanism attacks goes to the contender who can delete or manipulate log entries at a granular level, "as though the event never even happened!". Intrusion and deployment of rootkits allows an attacker to utilize specialized tools that may assist or automate the manipulation of known log files. In most cases, log files may only be manipulated by users with root / administrator privileges, or via approved log manipulation applications. As a general rule, logging mechanisms should aim to prevent manipulation at a granular level since an attacker can hide their tracks for a considerable length of time without being detected. Simple question; if you were being compromised by an attacker, would the intrusion be more obvious if your log file was abnormally large or small, or if it appeared like every other day's log?

===How to protect yourself ===

Assign log files the highest security protection, providing reassurance that you always have an effective 'black box' recorder if things go wrong. This includes:

Applications should not run with Administrator, or root-level privileges. This is the main cause of log file manipulation success since super users typically have full file system access. Assume the worst case scenario and suppose your application is exploited. Would there be any other security layers in place to prevent the application's user privileges from manipulating the log file to cover tracks?

Ensuring that access privileges protecting the log files are restrictive, reducing the majority of operations against the log file to alter and read.

Ensuring that log files are assigned object names that are not obvious and stored in a safe location of the file system.

Writing log files using publicly or formally scrutinized techniques in an attempt to reduce the risk associated with reverse engineering or log file manipulation.

Writing log files to read-only media (where event log integrity is of critical importance).

Use of hashing technology to create digital fingerprints. The idea being that if an attacker does manipulate the log file, then the digital fingerprint will not match and an alert generated.

Use of host-based IDS technology where normal behavioral patterns can be 'set in stone'. Attempts by attackers to update the log file through anything but the normal approved flow would generate an exception and the intrusion can be detected and blocked. This is one security control that can safeguard against simplistic administrator attempts at modifications.

==False Alarms ==

Taking cue from the classic 1966 film "How to Steal a Million", or similarly the fable of Aesop; "The Boy Who Cried Wolf", be wary of repeated false alarms, since this may represent an attacker's actions in trying to fool the security administrator into thinking that the technology is faulty and not to be trusted until it can be fixed.

===How to protect yourself ===

Simply be aware of this type of attack, take every security violation seriously, always get to the bottom of the cause event log errors rather, and don't just dismiss errors unless you can be completely sure that you know it to be a technical problem.

===Denial of Service ===

By repeatedly hitting an application with requests that cause log entries, multiply this by ten thousand, and the result is that you have a large log file and a possible headache for the security administrator. Where log files are configured with a fixed allocation size, then once full, all logging will stop and an attacker has effectively denied service to your logging mechanism. Worse still, if there is no maximum log file size, then an attacker has the ability to completely fill the hard drive partition and potentially deny service to the entire system. This is becoming more of a rarity though with the increasing size of today's hard disks.

===How to protect yourself ===

The main defense against this type of attack are to increase the maximum log file size to a value that is unlikely to be reached, place the log file on a separate partition to that of the operating system or other critical applications and best of all, try to deploy some kind of system monitoring application that can set a threshold against your log file size and/or activity and issue an alert if an attack of this nature is underway.

==Destruction ==

Following the same scenario as the Denial of Service above, if a log file is configured to cycle round overwriting old entries when full, then an attacker has the potential to do the evil deed and then set a log generation script into action in an attempt to eventually overwrite the incriminating log entries, thus destroying them.

If all else fails, then an attacker may simply choose to cover their tracks by purging all log file entries, assuming they have the privileges to perform such actions. This attack would most likely involve calling the log file management program and issuing the command to clear the log, or it may be easier to simply delete the object which is receiving log event updates (in most cases, this object will be locked by the application). This type of attack does make an intrusion obvious assuming that log files are being regularly monitored, and does have a tendency to cause panic as system administrators and managers realize they have nothing upon which to base an investigation on.

===How to protect yourself ===

Following most of the techniques suggested above will provide good protection against this attack. Keep in mind two things:

Administrative users of the system should be well trained in log file management and review. 'Ad-hoc' clearing of log files is never advised and an archive should always be taken. Too many times a log file is cleared, perhaps to assist in a technical problem, erasing the history of events for possible future investigative purposes.

An empty security log does not necessarily mean that you should pick up the phone and fly the forensics team in. In some cases, security logging is not turned on by default and it is up to you to make sure that it is. Also, make sure it is logging at the right level of detail and benchmark the errors against an established baseline in order measure what is considered 'normal' activity.

==Audit Trails ==

Audit trails are legally protected in many countries, and should be logged into high integrity destinations to prevent casual and motivated tampering and destruction.

===How to determine if you are vulnerable ===

* Do the logs transit in the clear between the logging host and the destination?

* Do the logs have a HMAC or similar tamper proofing mechanism to prevent change from the time of the logging activity to when it is reviewed?

* Can relevant logs be easily extracted in a legally sound fashion to assist with prosecutions?

===How to protect yourself ===

* Only audit truly important events – you have to keep audit trails for a long time, and debug or informational messages are wasteful

* Log centrally as appropriate and ensure primary audit trails are not kept on vulnerable systems, particularly front end web servers

* Only review copies of the logs, not the actual logs themselves

* Ensure that audit logs are sent to trusted systems

* For highly protected systems, use write-once media or similar to provide trust worthy long term log repositories

* For highly protected systems, ensure there is end-to-end trust in the logging mechanism. World writeable logs, logging agents without credentials (such as SNMP traps, syslog etc) are legally vulnerable to being excluded from prosecution

==Further Reading ==

* Oracle Auditing

http://www.sans.org/atwork/description.php?cid=738

* Sarbanes Oxley for IT security

http://www.securityfocus.com/columnists/322

* Java Logging Overview
http://java.sun.com/javase/6/docs/technotes/guides/logging/overview.html

==Error Handling and Logging ==

All applications have failures – whether they occur during compilation or runtime. Most programming languages will throw runtime exceptions for illegally executing code (e.g. syntax errors) often in the form of cryptic system messages. These failures and resulting system messages can lead to several security risks if not handled properly including; enumeration, buffer attacks, sensitive information disclosure, etc. If an attack occurs it is important that forensics personnel be able to trace the attacker’s tracks via adequate logging.

ColdFusion provides structured exception handling and logging tools. These tools can help developers customize error handling to prevent unwanted disclosure, and provide customized logging for error tracking and audit trails. These tools should be combined with web server, J2EE application server, and operating system tools to create the full system/application security overview.

'''Error Handling'''

Hackers can use the information exposed by error messages. Even missing templates errors (HTTP 404) can expose your server to attacks (e.g. buffer overflow, XSS, etc.). If you enable the Robust Exception Information debugging option, ColdFusion will display:

Physical path of template

URI of template

Line number and line snippet

SQL statement used (if any)

Data source name (if any)

Java stack trace

ColdFusion provides tags and functions for developers to use to customize error handling. Administrators can specify default templates in the ColdFusion Administrator (CFAM) to handle unknown or unhandled exceptions. ColdFusion’s structure exception handling works in the following order:

Template level (ColdFusion templates and components)

ColdFusion exception handling tags: cftry, cfcatch, cfthrow, and cfrethrow

try and catch statements in CFScript

Application level (Application.cfc/cfm)

Specify custom templates for individual exceptions types with the cferror tag

Application.cfc onError method to handle uncaught application exceptions

System level (ColdFusion Administrator settings)

Missing Template Handler execute when a requested ColdFusion template is not found

Site-wide Error Handler executes globally for all unhandled exceptions on the server

'''Best Practices '''

Do not allow exceptions to go unhandled

Do not allow any exceptions to reach the browser

Display custom error pages to users with an email link for feedback

Do not enable “Robust Exception Information” in production.

Specify custom pages for ColdFusion to display in each of the following cases:

When a ColdFusion page is missing (the Missing Template Handler page)

When an otherwise-unhandled exception error occurs during the processing of a page (the Site-wide Error Handler page)

You specify these pages on the Settings page in the Server Settings are in the ColdFusion MX Administrator; for more information, see the ColdFusion MX Administrator Help.

Use the cferror tag to specify ColdFusion pages to handle specific types of errors.

Use the cftry, cfcatch, cfthrow, and cfrethrow tags to catch and handle exception errors directly on the page where they occur.

In CFScript, use the try and catch statements to handle exceptions.

Use the onError event in Application.cfc to handle exception errors that are not handled by try/catch code on the application pages.

'''Logging'''

Log files can help with application debugging and provide audit trails for attack detection. ColdFusion provides several logs for different server functions. It leverages the Apache Log4j libraries for customized logging. It also provides logging tags to assist in application debugging.

The following is a partial list of ColdFusion log files and their descriptions''' '''

{| border=1

|| Log file || Description

|-

|| application.log || Records every ColdFusion MX error reported to a user. Application page errors, including ColdFusion MX syntax, ODBC, and SQL errors, are written to this log file.

|-

|| exception.log || Records stack traces for exceptions that occur in ColdFusion.

|-

|| scheduler.log || Records scheduled events that have been submitted for execution. Indicates whether task submission was initiated and whether it succeeded. Provides the scheduled page URL, the date and time executed, and a task ID.

|-

|| server.log || Records start up messages and errors for ColdFusion MX.

|-

|| customtag.log || Records errors generated in custom tag processing.

|-

|| mail.log || Records errors generated by an SMTP mail server.

|-

|| mailsent.log || Records messages sent by ColdFusion MX.

|-

|| flash.log || Records entries for Macromedia Flash Remoting.

|-

|}

The CFAM contains the Logging Settings and log viewer screens. Administrators can configure the log directory, maximum log file size, and maximum number of archives. It also allows administrators to log slow running pages, CORBA calls, and scheduled task execution. The log viewer allows viewing, filtering, and searching of any log files in the log directory (default is cf_root/logs). Administrators can archive, save, and delete log files as well.

The cflog and cftrace tags allow developer to create customized logging. <cflog> can write custom messages to the Application.log, Scheduler.log, or a custom log file. The custom log file must be in the default log directory – if it does not exist ColdFusion will create it. <cftrace> tracks execution times, logic flow, and variable at the time the tag executes. It records the data in the cftrace.log (in the default logs directory) and can display this info either inline or in the debugging output of the current page request. Use <cflog> to write custom error messages, track user logins, and record user activity to a custom log file. Use <cftrace> to track variables and application state within running requests.

'''Best Practices'''

Use <cflog> for customized logging

Incorporate into custom error handling

Record application specific messages

Actively monitor and fix errors in ColdFusion’s logs

Optimize logging settings

Rotate log files to keep them current

Keep files size manageable

Enable logging of slow running pages

Set the time interval lower than the configured Timeout Request value in the CFAM Settings screen

Long running page timings are recorded in the server.log

Use <cftrace> sparingly for audit trails

Use with inline=“false”

Use it to track user input – Form and/or URL variables

'''''Best Practices in Action'''''

The following code adds error handling and logging to the dbLogin and logout methods in the code from Authentication section.

{| border=1

||

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

<cffunction name="dblogin" access="private" output="false" returntype="struct">

<cfargument name="strUserName" required="true" type="string">

<cfargument name="strPassword" required="true" type="string">

<cfset var retargs = StructNew()>

<cftry>

<cfif IsValid("regex", uUserName, "[A-Za-z0-9%]*") AND IsValid("regex", uPassword, "[A-Za-z0-9%]*")>

<cfquery name="loginQuery" dataSource="#Application.DB#" >

SELECT hashed_password, salt

FROM UserTable

WHERE UserName =

<cfqueryparam value="#strUserName#" cfsqltype="CF_SQL_VARCHAR" maxlength="25">

</cfquery>

<cfif loginQuery.hashed_password EQ Hash(strPassword & loginQuery.salt, "SHA-256" )>

<cfset retargs.authenticated="YES">

<cfset Session.UserName = strUserName>

<cflog text="#getAuthUser()# has logged in!"

type="Information"

file="access"

application="yes">



<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfelse>

<cfset retargs.authenticated="NO">

</cfif>

<cfcatch type="database">

<cflog text="Error in dbLogin(). #cfcatch.details#"

type="Error"

log="Application"

application="yes">

<cfset retargs.authenticated="NO">

<cfreturn retargs>

</cfcatch>

</cftry>

<cfreturn retargs>

</cffunction>

<cffunction name="logout" access="remote" output="true">

<cfargument name="logintype" type="string" required="yes">

<cfif isDefined("form.logout")>

<cflogout>

<cfset StructClear(Session)>

<cflog text="#getAuthUser()# has been logged out."

type="Information"

file="access"

application="yes">

<cfif arguments.logintype eq "challenge">

<cfset foo = closeBrowser()>

<cfelse>



<cflocation url="login.cfm">

</cfif>

</cfif>

</cffunction>

|-

|}

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Error Handling]]
[[Category:Logging]]
[[Category:OWASP Logging Project]]

Canonicalization, locale and Unicode

2008-08-12T12:18:58Z

Joern.zaefferer: /* Description */ grammar mistake

[[Guide Table of Contents]]__TOC__

==Objective ==

To ensure the application is robust when subjected to encoded, internationalized and Unicode input.

==Platforms Affected ==

All.

==Relevant COBIT Topics ==

DS11.9 – Data processing integrity

==Description ==

Applications are rarely tested for Unicode exploits, and yet many are vulnerable due to the same sort of issues which allows HTTP Request Smuggling to work – every browser, web server, web application firewall or HTTP inspection agent, and other device treats user locale handling in different (and usually confusing) manner.

Canonicalization deals with the way in which systems convert data from one form to another. Canonical means the simplest or most standard form of something. Canonicalization is the process of converting something from one representation to the simplest form.

Web applications have to deal with lots of canonicalization issues from URL encoding to IP address translation. When security decisions are made based on less than perfectly canonicalized data, the application itself must be able to deal with unexpected input safely.

'''NB: To be secure against canonicalization attacks does not mean that every application has to be internationalized, but all applications should be safe when Unicode and malformed representations are entered. '''

==Unicode ==

Unicode Encoding is a method for storing characters with multiple bytes. Wherever input data is allowed, data can be entered using Unicode to disguise malicious code and permit a variety of attacks. RFC 2279 references many ways that text can be encoded.

Unicode was developed to allow a Universal Character Set (UCS) that encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few UCS transformation formats (UTF) with varying characteristics. UTF-8 has the characteristic of preserving the full US-ASCII range. It is compatible with file systems, parsers and other software relying on US-ASCII values, but it is transparent to other values.

The importance of UTF-8 representation stems from the fact that web-servers/applications perform several steps on their input of this format. The order of the steps is sometimes critical to the security of the application. Basically, the steps are "URL decoding" potentially followed by "UTF-8 decoding", and intermingled with them are various security checks, which are also processing steps.

If, for example, one of the security checks is searching for "..", and it is carried out before UTF-8 decoding takes place, it is possible to inject ".." in their overlong UTF-8 format. Even if the security checks recognize some of the non-canonical format for dots, it may still be that not all formats are known to it.

Consider the ASCII character "." (dot). Its canonical representation is a dot (ASCII 2E). Yet if we think of it as a character in the second UTF-8 range (2 bytes), we get an overlong representation of it, as C0 AE. Likewise, there are more overlong representations: E0 80 AE, F0 80 80 AE, F8 80 80 80 AE and FC 80 80 80 80 AE.

{| border=1

|| UCS-4 Range || UTF-8 Encoding

|-

|| ''0x00000000-0x0000007F'' || ''0xxxxxxx''

|-

|| ''0x00000080 - 0x000007FF'' || ''110xxxxx 10xxxxxx''

|-

|| ''0x00000800-0x0000FFFF'' || ''1110xxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x00010000-0x001FFFFF'' || ''11110xxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x00200000-0x03FFFFFF'' || ''111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|| ''0x04000000-0x7FFFFFFF'' || ''1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx''

|-

|}

Consider the representation C0 AE of a ".". Like UTF-8 encoding requires, the second octet has "10" as its two most significant bits. Now, it is possible to define 3 variants for it, by enumerating the rest of the possible 2 bit combinations ("00", "01" and "11"). Some UTF-8 decoders would treat these variants as identical to the original symbol (they simply use the least significant 6 bits, disregarding the most significant 2 bits). Thus, the 3 variants are C0 2E, C0 5E and C0 FE.

It is thus possible to form illegal UTF-8 encodings, in two senses:

* A UTF-8 sequence for a given symbol may be longer than necessary for representing the symbol.

* A UTF-8 sequence may contain octets that are in incorrect format (i.e. do not comply with the above 6 formats).

To further "complicate" things, each representation can be sent over HTTP in several ways:

'''In the raw'''. That is, without URL encoding at all. This usually results in sending non-ASCII octets in the path, query or body, which violates the HTTP standards. Nevertheless, most HTTP servers do get along just fine with non-ASCII characters.

'''Valid URL encoding'''. Each non-ASCII character (more precisely, all characters that require URL encoding - a superset of non ASCII characters) is URL-encoded. This results in sending, say, %C0%AE.

'''Invalid URL encoding'''. This is a variant of valid URL encoding, wherein some hexadecimal digits are replaced with non-hexadecimal digits, yet the result is still interpreted as identical to the original, under some decoding algorithms. For example, %C0 is interpreted as character number ('C'-'A'+10)*16+('0'-'0') = 192. Applying the same algorithm to %M0 yields ('M'-'A'+10)*16+('0'-'0') = 448, which, when forced into a single byte, yields (8 least significant bits) 192, just like the original. So, if the algorithm is willing to accept non-hexadecimal digits (such as 'M'), then it is possible to have variants for %C0 such as %M0 and %BG.

It should be kept in mind that these techniques are not directly related to Unicode, and they can be used in non-Unicode attacks as well.

http://www.example.com/cgi-bin/bad.cgi?foo=../../bin/ls%20-al

URL Encoding of the example attack:

http://www.example.com/cgi-bin/bad.cgi?foo=..%2F../bin/ls%20-al

Unicode encoding of the example attack:

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%9c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%pc../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%9v../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c0%qf../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%8s../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%1c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%9c../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%c1%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%e0%80%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%f0%80%80%af../bin/ls%20-al

http://www.example.com/cgi-bin/bad.cgi?foo=..%f8%80%80%80%af../bin/ls%20-al

===How to protect yourself ===

A suitable canonical form should be chosen and all user input canonicalized into that form before any authorization decisions are performed. Security checks should be carried out after UTF-8 decoding is completed. Moreover, it is recommended to check that the UTF-8 encoding is a valid canonical encoding for the symbol it represents.

http://www.ietf.org/rfc/rfc2279.txt?number=2279 

==Input Formats ==

Web applications usually operate internally as one of ASCII, ISO 8859-1, or Unicode (Java programs are UTF-16 example). Your users may be using another locale, and attackers can choose their locale and character set with impunity.

===How to determine if you are vulnerable ===

Investigate the web application to determine if it asserts an internal code page, locale or culture.

If the default character set, locale is not asserted it will be one of the following:

* HTTP Posts. Interesting tidbit: All HTTP posts are required to be ISO 8859-1, which will lose data for most double byte character sets. You must test your application with your supported browsers to determine if they pass in fully encoded double byte characters safely

* HTTP Gets. Depends on the previously rendered page and per-browser implementations, but URL encoding is not properly defined for double byte character sets. IE can be optionally forced to do all submits as UTF-8 which is then properly canonicalized on the server

* .NET: Unicode (little endian)

* JSP implementations, such as Tomcat: UTF8 - see “javaEncoding” in web.xml by many servlet containers

* Java: Unicode (UTF-16, big endian, '''''or''''' depends on the OS during JVM startup)

* PHP: Set in php.ini, ISO 8859-1.

'''NB: Many PHP functions make (invalid) assumptions as to character set and may not work properly when changed to another character set. Test your application with the new character set thoroughly!'''

===How to protect yourself ===

* Determine your application’s needs, and set both the asserted language locale and character set appropriately.

==Locale assertion ==

The web server should always assert a locale and preferably a country code, such as “en_US”, “fr_FR”, “zh_CN”

===How to determine if you are vulnerable ===

Use a HTTP header sniffer or even just telnet against your web server:

''HEAD / HTTP1.0''

Should display something like this:

''HTTP/1.1 200 OK''

''Date: Sun, 24 Jul 2005 08:13:17 GMT''

''Server: Apache/1.3.29''

''Connection: close''

''Content-Type: text/html;''''' charset=iso-8859-1'''

===How to protect yourself ===

Review and implement these guidelines:

http://www.w3.org/International/technique-index

At a minimum, select the correct output locale and character set.

==Double (or n-) encoding ==

Most web applications only check once to determine if the input is has been de-encoded into the correct Unicode values. However, an attacker may have doubly encoded the attack string.

===How to determine if you are vulnerable ===

* Use XSS Cheat Sheet double encoder utility to double encode a XSS string

http://ha.ckers.org/xss.html

* If the resultant injection is a successful XSS output, then your application is vulnerable

* This attack may also work against:

# Filenames
# Non-obvious items like report types, and language selectors
# Theme names

===How to protect yourself ===

* Assert the correct locale and character set for your application

* Use HTML entities, URL encoding and so on to prevent Unicode characters being treated improperly by the many divergent browser, server and application combinations

* Test your code and overall solution extensively

==HTTP Request Smuggling ==

HTTP Request Smuggling (HRS) is an issue detailed in depth by Klein, Linhart, Heled, and Orrin in a whitepaper found in the references section. The basics of HTTP Request Smuggling is that many larger solutions use many components to provide a web application. The differences between the firewall, web application firewall, load balancers, SSL accelerators, reverse proxies, and web servers allow a specially crafted attack to bypass all the controls in the front-end systems and directly attack the web server.

The types of attack they describe are:

* Web cache poisoning

* Firewall/IDS/IPS evasion

* Forward and backward HRS techniques

* Request hijacking

* Request credential hijacking

Since the whitepaper, several examples of real life HRS have been discovered.

===How to determine if you are vulnerable ===

* Review the whitepaper

* Review your infrastructure for vulnerable components

===How to protect yourself ===

* Minimize the total number of components that may interpret the inbound HTTP request

* Keep your infrastructure up to date with patches

==Further Reading ==

* IDS Evasion using Unicode

http://online.securityfocus.com/print/infocus/1232

* W3C Internationalization Home Page

http://www.w3.org/International/

* HTTP Request Smuggling

http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf

* XSS Cheat Sheet

http://ha.ckers.org/xss.html

[[Guide Table of Contents]]
[[Category:OWASP_Guide_Project]]
[[Category:Canonicalization]]
[[Category:Encoding]]