Cryptographic Failures in Web Applications | A02

Cryptographic Failures

Cryptographic Failures refers to the failures related to cryptography which often lead to leak/exposure of sensitive data. In OWASP Top 10 2017 list it is listed as Sensitive Data Exposure. One of the man reason behind sensitive data exposure is the improper cryptographic implementation or not using encryption at all. Some of the issues comes under this category are :

Sensitive data transmitted (via HTTP, FTP, SMTP, etc) or stored in clear-text (in database, files, etc).
Use of old or weak cryptographic algorithms.
Use of weak or default encryption keys or re-use of compromised keys.
Encryption not enforced or server certificates not validated while communicating with it.

The application relies on third party libraries libraries to perform the encryption on data, and when doing this there can be several things that can go wrong, some of them are as follows :

hardcoded keys/passwords : Hardcoded Passwords, also often referred to as Embedded Credentials, are plain text passwords or other secrets in source code. This can be easily revealed by simply inspecting the client side code of a application, or in binaries by simply listing the strings (strings command). In some cases the encryption key is saved alongside the encrypted text. This type of key management mistakes are often seen with encryption. Sometimes the key is hardcoded in a config file.

Weak Algorithm : Weak or outdated algorithm are often hidden inside libraries and application frameworks. Weak cryptography algorithms like MD5 or SHA1 are easily broken by attackers, revealing the plaintext. Developers often choose these outdated hashing algorithms for hashing secrets.

Insufficient Entropy : When developers are required to generate random values in their code, often the random values generated are not so random and they may be predictable. For example using the same sequence of number to generate keys. Insufficient randomness can make the ciphertext predictable.

Using your own crypto : writing your own cryptographic algorithm for encryption sounds cool, but if you don’t have a good understanding of cryptography then its very risky and its just matter of time that Your crypto code will be broken by someone in the future. It is recommended to use battle tested and widely accepted crypto libraries instead of re-inventing the wheel by writing your own code to do the same as it can result in bugs.

Remediation

The sensitive data exposure can be avoided by encrypting the data. In the application the data might be in two states 1. at-rest for example stored data in databases like passwords, user info, banking data etc. and 2. in-transit, means being sent from one location to other. The example of in-transit data are users credentials, credit/debit card details traveling through http. To secure the at-rest data make sure to use the modern, slow hashing algorithms and in case of passwords with random salt added. To secure in-transit data use SSL or TLS protocols (HTTPS). These generally use RSA or ECC algorithms, and are unbreakable till date. Some of the general steps/checklists are :

Analyze all the sensitive data that your application deals with and ensure that it’s encrypted at rest as well as in transit.
Make use of strong and well-established encryption schemes and if there is a flaw in a scheme being used in the existing apps, make sure to update it.
Never cache any sensitive data.
The passwords you are storing must be hashed and salted.
It is recommended to use a strong hashing algorithm with the use of salts to make password cracking harder.
Make sure that your system is not suffering from a lousy algorithm setup. Correct the issue immediately upon discovery.
Ensure that the application is encrypting appropriate data without leaving any critical data vulnerable to attack.

Cryptographic Failures in Web Applications | A02 – OWASP TOP 10 2021

Cryptographic Failures

Remediation

References

Published by Admin

Leave a Reply Cancel reply