About
In the 2021 iteration of the OWASP Top 10, Cryptographic Failures moved up one ranking to take the No. 2 spot. Its name also changed from “Sensitive Data Exposure” to “Cryptographic Failures”.
Description
Previously known as Sensitive Data Exposure, which is more of a broad symptom rather than root a cause, focuses on failures related to cryptography (or lack thereof). This failure is responsible for the exposure and leaking of data of critical and sensitive nature to ill-intended resources or people. Missing out on safeguarding such data leads to theft, public listing, breaches, and other problems.
Cryptographic failures are a major cause of exposure to sensitive data, which may include passwords, credit card numbers, medical records, and other personal information.
The most common error occurs with:
incorrect encryption or non-implementation, such as data transfer in plain text,
use of old and weak cryptographic algorithms,
failure to implement security protocols to transfer sensitive data such as HTTP, SMTP, and FTP.
The first step is to identify data protection needs during transmission and standstill. Passwords, credit card numbers, and other personal data and trade secrets require additional protection, especially if this information is covered by privacy laws under the EU General Data Protection Regulation (GDPR) or financial data protection regulations such as the PCI Data Security Standard (PCI DSS).
Reference here.
Prevention
Classify data processed, stored, or transmitted by an application. Identify which data is sensitive according to privacy laws, regulatory requirements, or business needs.
Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
Make sure to encrypt all sensitive data at rest.
Ensure up-to-date and strong standard algorithms, protocols, and keys are in place; use proper key management.
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).
Disable caching for response that contain sensitive data.
Apply required security controls as per the data classification.
Do not use legacy protocols such as FTP and SMTP for transporting sensitive data.
Store passwords using strong adaptive and salted hashing functions with a work factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
Initialization vectors must be chosen appropriate for the mode of operation. For many modes, this means using a CSPRNG (cryptographically secure pseudo random number generator). For modes that require a nonce, then the initialization vector (IV) does not need a CSPRNG. In all cases, the IV should never be used twice for a fixed key.
Always use authenticated encryption instead of just encryption.
Keys should be generated cryptographically randomly and stored in memory as byte arrays. If a password is used, then it must be converted to a key via an appropriate password base key derivation function.
Ensure that cryptographic randomness is used where appropriate and that it has not been seeded in a predictable way or with low entropy. Most modern APIs do not require the developer to seed the CSPRNG to get security.
Avoid deprecated cryptographic functions and padding schemes, such as MD5, SHA1, PKCS # 1 v1.5.
Verify independently the effectiveness of configuration and settings.
Reference here.
Potential impact
This vulnerability may have several different business impacts. Usually, broken cryptography will result in the following:
Privacy violations,
Information theft,
Code theft,
Intellectual property theft,
Reputation damage.
Reference here.
Common examples
Example #1: The app encrypts the credit card numbers in the database by automatically encrypting the database. However, this data is automatically decrypted on retrieval, allowing the SQL injection flaw to retrieve the credit card numbers in clear text.
Example #2: The website does not use or enforce TLS for all pages or supports weak encryption. The attacker monitors network traffic (e. g. on an unsecured wireless network), downgrades connections from HTTPS to HTTP, intercepts requests, and steals the user's session cookie. The attacker then replays this cookie and hijacks the user's (authenticated) session, accessing or modifying the user's private data. Instead of the above, you could change all the transferred data, for example, the recipient of the money transfer.
Example #3: The password database uses unsalted or simple hashes to store everyone's passwords. A file upload error allows an attacker to obtain the password database. All unsalted hashes can be highlighted with a rainbow table of pre-calculated CDs. GPUs can break CDs created by simple or fast compaction functions, even if they have been salted.
Cases
Google's Project Zero discovered an issue in Cloudflare's edge servers that allowed the extraction of memory that could contain sensitive data, some of which was cached by search engines. This security flaw has been dubbed Cloudbleed.
Cloudflare admitted that the leak could have started as early as 22 September 2016 and the private key between Cloudflare devices had expired. With almost 6 million websites using Cloudflare services and many web application defences built on the assumption of a secure TLS communication channel, the impact could be significant. Cloudflare estimates that the error was triggered 1,242,071 times between 22 September 2016 and 18 February 2017.
Cloudflare conducted a small sample study with a confidence level of 99% and a margin of error of 2. 5%, which showed a limited amount of sensitive data exposed.
____________________________________________________________________________________________
References and more information:
Last updated