Dev Overflow – Part 5

By Mikhail Sudakov, Cyber Security Architect and Analyst, LEO Cyber Security.

Back to Part 4

Is your application vulnerable to sensitive data exposure? To answer that question, we need to know if it is storing sensitive data. Naturally, we cannot answer the latter without knowing what those sensitive data are in a given context.

A3 – Sensitive Data Exposure

Man in the Middle attacker sniffs the network and can view and modify packets in transit.

“Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.” – (OWASP).

Before we can hope to protect sensitive data better, we must understand what they are. In some contexts, it may not be as simple of a problem as it sounds. Depending on laws and/or regulations, there may be unusual additional requirements to protect certain types of information. Therefore, it is very important to fully understand all of those laws and regulations to properly identify and protect those sensitive data. There are, however, many well-known and common examples, such as credentials (username-password pairs), SSN/SIN/other crucial government ID number, credit/bank card and other financial info, addresses and phone numbers, date/place of birth, passport/license numbers, medical data, answers to security questions (side note: I won’t go into this here, but it is generally a really bad idea to provide truthful answers to security questions! I may write a blog post on that in the future.), and other PII (Personally-Identifiable Information).

“Over the last few years, this has been the most common impactful attack.” – (OWASP). You may have already guessed why, and the answer is: identity theft and fraud! Hopefully it doesn’t come as a surprise that today our identities are pretty much fully digital, and it is incredibly easy to impersonate someone. Moreover, digital identities have been a high-demand item on the black markets in the darker parts of the web for years now. Unless we want to be in the news with the reputation-destroying heading of “Massive Data Breach – Millions of Accounts Stolen!“, it is absolutely imperative that we properly identify and protect sensitive data. We must do this or suffer terrible consequences; everything can be fixed, except for reputation and trust. Oftentimes, once it’s gone – it’s gone.

Know Your Data

This is a given and a must. Proper identification and classification of data that is processed, stored, or transmitted by our application must be regularly conducted. Few would argue that it is hard to protect the unknown. Furthermore, it is necessary to properly apply access controls.

The Principle of Least Privilege

Although it may not seem like it applies in this context, it absolutely does in the sense that we should only ever store and keep sensitive data that we must have and no more. Don’t be a hoarder of unnecessary sensitive data and discard it immediately! It is often very useful to mine and hoard data, no argument there; but if we hoard sensitive data that we do not absolutely have to have, we are shooting ourselves in the foot. The less sensitive data we have, the easier they are to keep track of and protect.

Encrypt All Sensitive Data

All sensitive data must be encrypted both at rest and in transit. Transmitting sensitive data in plaintext (not encrypted) is a horrible blunder that will land us in hot (probably even boiling) water in no time. And encrypting our data only in transit opens us up to a theft of our main data stores and leakage of all sensitive data from there. Remember that breaches are inevitable; and as was stated in earlier posts, they are a question of when, not if. It is essential that all sensitive data are encrypted at rest as well as in transit.

Using Bad Crypto is Worse Than Using No Crypto at All

You read that correctly. Just like having bad and unreliable info is worse than having none at all, the same applies to crypto. I hope it is obvious that using bad crypto provides a sense of “security” that is FALSE, and I would argue that is way worse. As previously stated, it is incredibly easy to implement and use crypto very wrong. Encrypting sensitive data properly and accurately is beyond the scope of this blog post, but OWASP has great information on this topic and more if you would like to read up on this further.

The next post will discuss OWASP A4 – XML External Entities.


    Leave a Comment