Penn Computing

Penn Computing

Computing Menu Computing A-Z
Computing Home Information Systems & Computing Penn

 

Sunday, October 26, 2014

 
  New Resources
Travel Tips for Data Security
Free Security/Privacy Training Resources
Penn+Box
Two-step verification
Combating Malware
SafeDNS
Phishing Archive
Cloud Computing and Data Outsourcing
Best Practices for Applications with Confidential University Data
 
  Security "Greatest Hits"
Managing Passwords
E-mail Harassment & Forgery
Hoaxes, frauds & scams
Spam
Phishing
Wireless Networking
Encryption & digital signatures
 
  Best Practices
Secure desktop computing
Secure servers
Secure data deletion
Securing printers
Tips for safe computing
Computing policies
 
  More in-depth information for
Local support providers
System administrators
 
  Security initiatives
Critical host compliance
Authentication & authorization
Penn Security & Privacy Assessment (SPIA)
Security Liaisons (Restricted Access)
Secure Share
Secure Space
Vulnerability Scanner
 
  Related links
Electronic privacy
PennKey
Viruses
Worms, trojans, backdoors

Top 10 Web Application Security Vulnerabilities

Based on OWASP Research

A8: Insecure Storage

A8.1 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.

A8.2 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.

A8.3 Examples and References

A8.4 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.

A8.5 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, such as SHA-1, 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.

 

top

Information Systems and Computing
University of Pennsylvania
Comments & Questions


Penn Computing University of Pennsylvania
Information Systems and Computing, University of Pennsylvania