This blog entry is also available as a TechRepublic download in PDF form.
In this final installment of the revised Open Web Application Security Project (OWASP) Top 10 series, the final three vulnerabilities are explored — insecure cryptographic storage, insecure communications, and failure to restrict URL access. The final three vulnerabilities in the 2007 OWASP Top 10 are closely related. They all deal with failure to take appropriate steps to safeguard access to data. Let’s look at each of these Web application weaknesses, how to verify they exist, and the steps organizations can take to mitigate the risk associated with them.
Insecure cryptographic storage
Insecure cryptographic storage is volatile or non-volatile storage in which sensitive information is stored without reasonable and appropriate encryption. In other words, the storing of things like unencrypted passwords, encryption keys, or Electronic Protected Health Information (ePHI) in locations where a determined attacker can potentially access them is a bad idea.
It’s not uncommon for me to find user IDs and passwords, in plain text, included in text files on Web or application servers. It’s also not uncommon for a developer to use a nonstandard encryption algorithm — including one of his own creation — to encrypt sensitive information. In both situations, valuable information is relatively easy to access by both internal and external attackers who know where to look.
Finally, we come to databases. Databases are the repository of all critical and sensitive information in an enterprise. The level of security required for each database server, database, or table depends on the classification of the data residing in it. Simply applying user ID and password access controls may not be enough to demonstrate due diligence.
Verifying the presence of insecure cryptographic storage
According to the OWASP, there is no effective way to detect weaknesses in encryption methods or algorithms. The best way to determine whether an organization’s approach to encryption is sound is to review documented processes and policies.
Organizations should ensure risk assessments check for the vulnerability of sensitive information. They should validate that ePHI, PII, passwords, keys, and certificates are properly safeguarded in accordance with documented procedures.
How to secure storage
Supplementing role-based access control methods with encryption is the best way to protect stored data in a business environment. However, encryption carries with it a new set of security considerations. The following are OWASP recommendations for maintaining an effective encryption environment:
- Do not create cryptographic algorithms: Choose an encryption library that has been exposed to public scrutiny. Ensure there are no open vulnerabilities in the library you select.
- Do not use weak algorithms: Don’t use encryption algorithms that are known to have been cracked. Use the strongest encryption algorithms possible given your processing environment.
- Generate keys offline and store private keys with care: Ensure the safe storage of keys, certificates, and passwords. Split master secrets into two parts to be reassembled at runtime.
- Ensure that infrastructure credentials, such as those for database or message queue access details, are properly secured.
- Never store unnecessary data: The easiest data to protect are data that weren’t stored in the first place. Never store sensitive information that isn’t an absolute operational necessity.
Information has no value if it simply sits on a disk somewhere. To have business value, data must be delivered to endpoint devices or servers for processing. However, data are most vulnerable when in transit. Insecure communications result from a failure to properly secure internal and external information interfaces.
The most obvious insecure interface is remote access to sensitive data via the Internet. Under no circumstances should this type of access occur without first creating a secure session. The most common way to accomplish this is through the use of SSL. Company-owned and controlled endpoint devices might also employ VPN to create a “private” connection over the Internet.
Another common external interface involves transferring data between organizations. For example, a health care company might transmit insurance information to a clearinghouse for processing. The files transferred are rife with ePHI. VPN is a good solution if the connection required is more permanent. If files are transmitted only once per day, a temporary SSL connection or the use of secure FTP might suffice.
Finally, there’s the connection between Internet-facing application servers in a DMZ and database servers on the internal network. SSL and IPSec are good ways to encrypt data between these two types of devices.
Although safer than external interfaces, connections between devices on the internal network can expose data to greater than acceptable risk. This is especially true if data passes through trust boundaries. A trust boundary is crossed when data moves between locations with different trust/security levels. For example, data moving from a high trust VLAN through a low trust network segment in route to second high trust VLAN should be encrypted.
Verifying secure communications
Using vulnerability scanners against external interfaces is a good start. This can locate both insecure interfaces and potential weaknesses in SSL configurations. Interface scanning should be combined with vulnerability scans of internal network segments. Trust boundaries should be identified and threat models created to identify potential attack vectors.
Failure to restrict URL access
This vulnerability was touched upon in Part 5 of this series, under Insecure Direct Object Reference. A Web application/site with this weakness allows an attacker to retrieve URLs by “guessing” the address. This is one instance where security-through-obscurity isn’t enough protection.
As with insecure direct object reference vulnerabilities, developers and site administrators must be careful to lock down any folder or directory in which non-public pages and files are stored. In a Microsoft Windows environment, this would start with establishing NTFS and share permissions. Other considerations, provided in the OWASP Top 10 documentation, include:
- Perform penetration tests: As always, identify potential attack vectors and test the application’s vulnerability. A good approach to this process can be found in Managing risk starts with asking the right questions.
- Pay close attention to include/library files: These files should be kept out of the Web root whenever possible and accessed only through secure application methods.
- Block access to all file types your application should never serve.
The final word
Over the past several weeks, I’ve explored the details of the 2007 OWASP Top 10. However, I’ve only scratched the surface. The OWASP Web site (OWASP.org) contains a large amount of useful information and examples. I recommend that every developer and site administrator take the time to browse through this material. Improving awareness of both what to do, as well as what not to do, will improve our ability to provide safe information delivery over the Internet.