Miscellaneous Security

Reading time: 3 – 4 minutes

Photo: fpsurgeon

This is the eighth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Insecure Cryptographic Storage

Insecure cryptographic storage occurs when an application doesn’t securely encrypt it’s sensitive data when it is stored into a database. This definition is similar to the picture above, recursive.

Simply stated, insecure cryptographic storage occurs when one of following happens:

1. The developers don’t encrypt the data that is being stored in the database.
2. The developers do encrypt the data being stored in the database, but they rely on encryption methods they have developed. (Also known as home-grown cryptography)

After reading these two points you may say, “only an idiot wouldn’t encrypt sensitive data being stored in the database.” I refer you to number two in the list above.

If you think you are smart enough to write your own cryptographic algorithms, you my friend, are the idiot.

The main business concern with not encrypting sensitive data is that it can lead to confidentiality loss. All companies are concerned with unauthorized individuals viewing their sensitive data. In addition, encrypting sensitive data is be a regulatory compliance. (See PCI-DSS requirement 3.)

An Example of Insecure Cryptographic Storage

Here is a simplified example. Selecting the users table from a database we are returned the following:

> select * from users;

The passwords in these table are 32 characters long. Could these passwords be MD5 hashes?

As with all hashing algorithms, MD5 hashes can’t be reversed. However, they can be pre-computed. Using a site like, gdataonline, we can identify what the password is before it was ran through the MD5 hashing algorithm.

After inserting 5f4dcc3b5aa765d61d8327deb882cf99 into the online form the resulting password is returned. In this example, the password is “password.”

How Do You Prevent Insecure Cryptographic Storage From Occurring

If the data is sensitive and stored it NEEDS to be encrypted. Examples of items that are considered to be sensitive can include:

• Credit Cards
• User Names
• Passwords
• User data

There are other things to keep in mind when making sure you securely store information. This includes not creating your own cryptographic algorithms. No matter how smart you or your peers think you are DO NOT attempt to invent a new encryption algorithm. Leave this work to the experts.

Ensure that the data stored is not easy to decrypt. This can usually be averted by not using known weak algorithms such as RC3, RC4, MD5 and SHA-1.

If you are using asymmetric key encryption make sure to store your private keys carefully. If an attacker gets hold of the private key, you might as well not encrypt the data in the first place.

Reading time: 3 – 4 minutes

Photo: Stephen Poff

This is the seventh-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Broken Authentication and Session Management

When developers are programming web application based solutions they rarely focus on how the user’s session is managed. Failing to keep this in mind can lead developers to introduce session management vulnerabilities in their applications.

Session management vulnerabilities occur when developers fail to protect their users sensitive information such as user names, passwords, and session tokens.

Broken authentication vulnerabilities occur when developers fail to use authentication methods that have been adequately tested and rely on their own, often flawed, method for authenticating users.

These vulnerabilities are very hard for developers to identify on their own due to the far-reaching aspect of the code that handles session and authentication.

An Example of Broken Authentication and Session Management

Due to the broad reach of this vulnerability there are many examples of broken authentication and session management occurring. Examples include forgotten password functionality, emailing user credentials, relying on IP address for session, not authenticating a user before changing a password, and not having adequate timeouts for inactive sessions.

Forgotten Password Functionality

Web applications often have a forgotten password functionality that allows a user to submit their user name to the application and are taken to a page with secret questions or a temporary password reset function.

Attackers can exploit this functionality to enumerate valid user name for the application. Developers often forget that a user name is half the puzzle to an attacker. Is an attacker knowing a password damaging if they don’t know a user name to go along with it?

How Do You Prevent Broken Authentication and Session Management

Protecting credentials and session cookies is one of the most difficult tasks for a developer. Protecting this critical pieces of data can touch on many lines of code in several different files.

To prevent these types of vulnerabilities from occurring in your application, developers should first ensure that SSL is used for all authenticated parts of the application. In addition, verify that all credentials are stored in a hashed form.

As with all prevention methods preventing these vulnerabilities takes careful planning from the design stage of the application. The following should all be considered:

• Only use the native session management mechanism. Do not write your own session handlers. Do not use home-grown cookies for authentication or session-management.
• Use a single authentication mechanism. Again, do not write your own authentication mechanism.
• Do not allow the login process to happen from an unencrypted page.
• Once a user authenticates, issue them a new session cookie and invalidate the previous session cookie. This will prevent session hijacking attacks from occurring.
• Verify that every page of the application has a logout link that is easily identified by the user.
• Have adequate timeouts for inactive sessions. Shorter is better.
• Verify the user knows their old password before changing their password.
• Do not send credentials (including the user name) over insecure channels, such as email.
• Do not expose session identifiers, such as the session token, in the URL.

Reading time: 2 – 4 minutes

Photo: Andres Ruedahis

This is the sixth-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Information Leakage and Improper Error Handling

Information leakage and improper error handling happen when web applications do not limit the amount of information they return to their users. A classic example of improper error handling is when an application doesn’t sanitize SQL error messages that are returned to the user. Upon receiving a SQL error message an attacker will immediately identify a place for identifying injection flaws.

Although preventing error messages from reaching users will not prevent vulnerabilities from occurring, it does make it difficult for an attacker to accomplish his goal and it is also an industry best practice.

An Example of Information Leakage

Common examples of information leakage include helpful error messages and service banners. Developers and system administrators often forget or disregard how something as simple as a server banner can be used by an attacker.

As an example, if your server is running Apache and you return the server header with your responses, an attacker could leverage this to fingerprint the version of the web server you are running.

Using nmap an attacker could send a few packets at your application server using the command, nmap -sV -p 80 192.168.1.100 and identify the following:

Interesting ports on 192.168.38.132:
PORT    STATE SERVICE  VERSION
80/tcp  open  http     Apache httpd 1.3.37

The attacker has now identified your Apache version and can now search for vulnerabilities affecting that version of Apache.

An Example of Improper Error Handling

Attackers attempt to leverage information that applications freely volunteer. If an application displays an error messages to the user (attacker), there is not guarantee that the user will “ignore” this error message.

Developers typically forget to properly handle their error messages. Stack traces and SQL errors are two examples of very commonly forgotten errors that should be handled.

Attackers love seeing error messages such as:

ERROR:  unterminated quoted string at or near "'''"

How Do You Prevent Information Leakage and Improper Error Handling

When developing applications, developers should assume all of the users are hostile. As a developer having this mentality will greatly aid you in developing secure applications.

All information returned from a web server should be reviewed for potential leakage. This can be automated by a QA team using a fuzzer.

Developers should also use a standard exception handling architecture to prevent information leakage from occurring. This architecture should be used and shared across the entire development team. All developers should handle their errors the same way.

Developers or product managers may also decide to create a default error handler which returns sanitized error messages for most users in production for all error paths. Doing this will greatly reduce the attack surface that can be exploited through error message generation.