This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "Insecure Storage"
m |
m (removed deprecated SHA-1) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
==Description== | ==Description== | ||
| − | Most web applications have a need to store sensitive information, either in a database or on a file system somewhere. The information might be passwords, credit card numbers, account records, or proprietary information. Frequently, encryption techniques are used to protect this sensitive information. While encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it into a web application. Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the site. A few areas where mistakes are commonly made include: | + | Most web applications have a need to store sensitive information, either in a database or on a file system somewhere. The information might be passwords, credit card numbers, account records, or proprietary information. Frequently, encryption techniques are used to protect this sensitive information. While encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it into a web application. Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the site. |
| + | |||
| + | A few areas where mistakes are commonly made include: | ||
| + | |||
| + | * Failure to encrypt critical data | ||
| + | * Insecure storage of keys, certificates, and passwords | ||
| + | * Improper storage of secrets in memory | ||
| + | * Poor sources of randomness | ||
| + | * Poor choice of algorithm | ||
| + | * Attempting to invent a new encryption algorithm | ||
| + | * Failure to include support for encryption key changes and other required maintenance procedures | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
The impact of these weaknesses can be devastating to the security of a website. Encryption is generally used to protect a site’s most sensitive assets, which may be totally compromised by a weakness. | The impact of these weaknesses can be devastating to the security of a website. Encryption is generally used to protect a site’s most sensitive assets, which may be totally compromised by a weakness. | ||
| Line 18: | Line 21: | ||
==Examples and References== | ==Examples and References== | ||
| − | * [[:Category:OWASP_Guide_Project|OWASP Guide]] to Building Secure Web Applications and Web Services | + | * [[:Category:OWASP_Guide_Project|OWASP Guide]] to Building Secure Web Applications and Web Services |
| − | Bruce Schneier, “Applied Cryptography”, 2nd edition, John Wiley & Sons, 1995 | + | * Bruce Schneier, “Applied Cryptography”, 2nd edition, John Wiley & Sons, 1995 |
==How to Determine If You Are Vulnerable== | ==How to Determine If You Are Vulnerable== | ||
| Line 29: | Line 32: | ||
==How to Protect Yourself== | ==How to Protect Yourself== | ||
| − | The easiest way to protect against cryptographic flaws is to minimize the use of encryption and only keep information that is absolutely necessary. For example, rather than encrypting credit card numbers and storing them, simply require users to re-enter the numbers. Also, instead of storing encrypted passwords, use a one-way function | + | The easiest way to protect against cryptographic flaws is to minimize the use of encryption and only keep information that is absolutely necessary. For example, rather than encrypting credit card numbers and storing them, simply require users to re-enter the numbers. Also, instead of storing encrypted passwords, use a recent one-way hash function (such as SHA-256) to hash the passwords. |
If cryptography must be used, choose a library that has been exposed to public scrutiny and make sure that there are no open vulnerabilities. Encapsulate the cryptographic functions that are used and review the code carefully. Be sure that secrets, such as keys, certificates, and passwords, are stored securely. To make it difficult for an attacker, the master secret should be split into at least two locations and assembled at runtime. Such locations might include a configuration file, an external server, or within the code itself. | If cryptography must be used, choose a library that has been exposed to public scrutiny and make sure that there are no open vulnerabilities. Encapsulate the cryptographic functions that are used and review the code carefully. Be sure that secrets, such as keys, certificates, and passwords, are stored securely. To make it difficult for an attacker, the master secret should be split into at least two locations and assembled at runtime. Such locations might include a configuration file, an external server, or within the code itself. | ||
| − | |||
| − | |||
__NOEDITSECTION__ | __NOEDITSECTION__ | ||
Latest revision as of 07:43, 28 November 2013
Description
Most web applications have a need to store sensitive information, either in a database or on a file system somewhere. The information might be passwords, credit card numbers, account records, or proprietary information. Frequently, encryption techniques are used to protect this sensitive information. While encryption has become relatively easy to implement and use, developers still frequently make mistakes while integrating it into a web application. Developers may overestimate the protection gained by using encryption and not be as careful in securing other aspects of the site.
A few areas where mistakes are commonly made include:
- Failure to encrypt critical data
- Insecure storage of keys, certificates, and passwords
- Improper storage of secrets in memory
- Poor sources of randomness
- Poor choice of algorithm
- Attempting to invent a new encryption algorithm
- Failure to include support for encryption key changes and other required maintenance procedures
The impact of these weaknesses can be devastating to the security of a website. Encryption is generally used to protect a site’s most sensitive assets, which may be totally compromised by a weakness.
Environments Affected
Most web application environments include some form of cryptographic support. In the rare case that such support is not already available, there are a wide variety of third-party products that can be added. Only web sites that use encryption to protect information in storage or transit are susceptible to these attacks. Note that this section does not cover the use of SSL, which is covered in A10 Insecure Configuration Management. This section deals only with programmatic encryption of application layer data.
Examples and References
- OWASP Guide to Building Secure Web Applications and Web Services
- Bruce Schneier, “Applied Cryptography”, 2nd edition, John Wiley & Sons, 1995
How to Determine If You Are Vulnerable
Discovering cryptographic flaws without access to the source code can be extremely time consuming. However, it is possible to examine tokens, session IDs, cookies and other credentials to see if they are obviously not random. All the traditional cryptanalysis approaches can be used to attempt to uncover how a web site is using cryptographic functions.
By far the easiest approach is to review the code to see how the cryptographic functions are implemented. A careful review of the structure, quality, and implementation of the cryptographic modules should be performed. The reviewer should have a strong background in the use of cryptography and common flaws. The review should also cover how keys, passwords, and other secrets are stored, protected, loaded, processed, and cleared from memory.
How to Protect Yourself
The easiest way to protect against cryptographic flaws is to minimize the use of encryption and only keep information that is absolutely necessary. For example, rather than encrypting credit card numbers and storing them, simply require users to re-enter the numbers. Also, instead of storing encrypted passwords, use a recent one-way hash function (such as SHA-256) to hash the passwords.
If cryptography must be used, choose a library that has been exposed to public scrutiny and make sure that there are no open vulnerabilities. Encapsulate the cryptographic functions that are used and review the code carefully. Be sure that secrets, such as keys, certificates, and passwords, are stored securely. To make it difficult for an attacker, the master secret should be split into at least two locations and assembled at runtime. Such locations might include a configuration file, an external server, or within the code itself.
