Sensitive Data Exposure

Cracks in the shell

Valuable information that people can steal or use against us include credit cards, medical records, insurance files, purchasing data, and emails. This is the stuff that makes for headlines and subpoenas. That’s what OWASP means by “sensitive data.” The “exposure” part is probably obvious. Exposure doesn’t mean that a hacker broke our crypto. Hackers don’t attack our strong points. They look for cracks in our shell. It can be as simple as an employee’s stolen laptop with a database extract in a spreadsheet. Maybe our system uses TLS at the edge but REST over plain HTTP internally, another “pie crust.” An attacker can sniff the network to collect credentials and payload data.

Here are some guidelines to help you avoid headlines:

• Don’t store sensitive information that you don’t need. In retail, use a credit card tokenizer from your payment provider.

• Use HTTP Strict Transport Security. This is a step beyond HTTPS-first. It prevents clients from negotiating their way to insecure protocols.

• Stop using SHA-1. Just stop. It’s no longer adequate.

• Never store passwords in plain text. Read OWASP’s Password Storage Cheat Sheet for guidance on hash algorithms and good salting $^{13}$.

• Make sure sensitive data is encrypted in the database. It’s a pain, but it’s necessary.

• Decrypt data based on the user’s authorization, not the server’s.

AWS key management service

If you are in the AWS cloud, consider using AWS Key Management Service (KMS) $^{14}$ . KMS creates and manages master keys. Applications can request data encryption keys, which they use to encrypt or decrypt data. The data encryption keys are themselves encrypted with a “key encryption key.” It gets kind of recursive, but the point is that you don’t leave decryption keys laying around where an attacker could retrieve them. If you’re running on your own premises, consider HashiCorp’s Vault $^{15}$ . It manages “secrets” a bit more broadly than KMS. Regardless of which tool you pick, don’t try to hold it at arm’s length. Use the tool fully as part of a holistic secure development process.

Insufficient attack protection

Consider a production service protected by a firewall. It should be safe from attackers. Sadly, that is not the case. We must always assume that attackers have unlimited access to other machines behind the firewall. They can make arbitrary requests. That includes well-formed requests for unauthorized data, and it includes malformed requests aimed at compromising the service itself.

Services do not typically track illegitimate requests by their origin. They do not block callers that issue too many bad requests. That allows an attacking program to keep making calls, either to probe for weaknesses or extract data.

Your service probably detects bad input and rejects it like a closed pistachio. That leaves the attacker free to keep issuing requests. The service should log bad requests by source principal. Log collection tools, which we covered in Logs and Stats, can collate those requests to find patterns.

Certificate revocation list

It’s probably not feasible to give every service a whitelist of allowed consumers. After all, we want consumers to be deployed on their own, without centralized control. We can, however, give a service a blacklist of disallowed consumers. This may be stored as a certificate revocation list (CRL) or by principal name in your authentication system (active directory name, for example). API Gateways are a useful defense here. An API gateway can block callers by their API key. It can also throttle their request rate. Normally, this helps preserve capacity. In the case of an attack, it slows the rate of data compromise, thereby limiting the damage. Network devices may help if our service is in a data center under our control. Application-layer firewalls (also called “layer 7 firewalls") can detect and block suspicious calls. They can also be loaded with signatures of well-known attacks to block probes.