OWASP Top 10 – A02 Cryptographic Failures - Part 2
This is part 2 of my posts on Cryptographic Failures. It is part of a series of blog posts about the OWASP Top 10 . Cryptographic failures remain one of the leading causes of data breaches, and understanding them is key for developers.
This post continues number 2 on the OWASP Top 10 list (2021): Cryptographic Failures . I’m writing this post as part of my own learning, and I hope it helps others along the way. I would highly recommend reading the entire OWASP page to gain an understanding of the nature of the vulnerability.
You can find the OWASP Top 10 List here .
In part 1, we looked at items 1 through 4 on the OWASP cryptographic failures prevention list. In this post, we’ll look at items 5 through 8. We will continue with the high-level summary review and deep-dive into specific concepts in upcoming posts.
OWASP states:
“Encrypt all data in transit with secure protocols such as TLS with forward secrecy (FS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).”(https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )
In Part 1 of the A02 series of posts, we discussed how we must ensure all sensitive data at rest is encrypted. However, encrypting sensitive data at rest is only part of the whole picture. We must also encrypt all data in transit. Furthermore, we must ensure that secure protocols, such as TLS with forward secrecy (FS) ciphers, are used.
Encrypting all data in transit ensures that any data sent across the network is protected from interception or tampering. It’s often impractical to determine which data in transit is sensitive, so encrypting all network traffic is the safest approach.
While all network traffic sent across the public internet should be encrypted in transit, data within an organization’s internal networks should be encrypted in transit as well.
OWASP states:
“Disable caching for response that contain sensitive data.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )
Caching sensitive data presents a security risk. Caches can exist at several layers. The user’s browser, proxy servers or content delivery networks (CDNs) are just a few examples. Each can potentially store cached information that should never be reused or shared.
Caching sensitive data can lead to:
- Exposure of sensitive data to unauthorized individuals.
- Cache poisoning attacks, where attackers manipulate cached content.
- Display of “stale” data to a user, which could cause data integrity issues, leading to incorrect decisions or security vulnerabilities.
OWASP states:
“Apply required security controls as per the data classification.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )
In Part 1, we looked at OWASP’s requirement to classify data processed, stored, or transmitted by an application—To identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
Once the data is classified, the next step is to apply required security controls that match the sensitivity of the data. Not all data needs the same level of protection. For example:
- Confidential or regulated data, such as PII/PHI, should be encrypted both in transit and at rest.
- Internal business data that isn’t confidential, such as IIS access logs for a public website, might not need encryption, but should still have restricted access and should be monitored for misuse.
- User passwords should never be stored in plain text. They must be hashed with a strong, current algorithm.
OWASP states:
“Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.” (https://owasp.org/Top10/A02_2021-Cryptographic_Failures/#how-to-prevent )
Only secure, encrypted protocols should be used to transport sensitive data. FTP and SMTP send data and credentials in cleartext. Even FTPS (FTP over SSL/TLS) is generally replaced by SFTP, which encrypts both authentication and data using SSH. The same applies to HTTP. Always use HTTPS to encrypt data in transit.
For email, use SMTPS, which stands for SMTP over TLS. Note the “S” or “SSL” in protocol names is just a carryover from the older SSL protocol. It now is generally understood to mean “TLS”. TLS 1.2 or later should always be used for encrypted data in transit.
In this post, we continued our look at cryptographic failures – Item #2 on the OWASP Top 10 list as of 2021. We looked at the next four items on the OWASP prevention list for this category of vulnerability. In the next post, we’ll continue working through OWASP’s prevention guidance for cryptographic failures, looking at additional best practices to help prevent cryptographic failures.