When an application stores or uses information that is sensitive in some way (credit card numbers, social security numbers, health records, passwords, and so on), special measures should be taken to protect it, as it could result in severe reputational, economic, or even legal damage to the organization that is responsible for its protection and suffers a breach that compromises it.
The sixth place in OWASP Top 10 is the sensitive data exposure, and it happens when data that should be specially protected is exposed in clear-text or with weak security measures.
In this recipe, we will cover some of the best practices when handling, communicating, and storing this type of data.
- If the sensitive data you use can be deleted after use, do it. It is much better to ask users every time for their credit card than have it stolen in a breach.
- When processing payments, always prefer the use of a payment gateway instead of storing such data in your servers. Check http://ecommerce-platforms.com/ecommerce-selling-advice/choose-payment-gateway-ecommerce-store for a review on top providers.
- If we have the need to store sensitive information, the first protection we must give to it is to encrypt it using a strong encryption algorithm with the corresponding strong keys adequately stored. Recommended algorithms are Twofish, AES, RSA, and Triple DES.
- Passwords, when stored in databases, should be stored in hashed form through one-way hashing functions, such as bcrypt, scrypt, or SHA-2.
- Be sure that all sensitive documents are only accessible by authorized users; don't store them in the Web server's document root but in an external directory and access them through programming. If, for some reason it is necessary to have sensitive documents inside the server's document root, use a
.htaccessfile to prevent direct access:Order deny,allow Deny from all
- Disable caching of pages that contain sensitive data. For example, in Apache we can disable the caching of PDF and PNG files by the following settings in
httpd.conf:<FilesMatch ".(pdf|png)> FileETag None Header unset ETag Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" Header set Pragma "no-cache" Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT" </FilesMatch>
- Always use secure communication channels to transfer sensitive information, namely HTTPS with TLS or FTPS (FTP over SSH) if you allow the uploading of files.
When it comes to protecting sensitive data, we need to minimize the risk of that data being leaked or traded with; that's why storing the information correctly encrypted and protecting the encryption keys is the first thing to do. If there is a possibility of not storing such data, it is the ideal option.
Passwords should be hashed with a one-way hashing algorithm before storing them in the database. So, if they are stolen, the attacker won't be able to use them immediately and if the passwords are strong and hashed with strong algorithms it won't be able to break them in a realistic time.
If we store sensitive documents or sensitive data in the document root of our server (/var/www/html/ in Apache, for example), we expose such information to be downloaded by its URL. So, it's better to store it somewhere else and make special server side codes to retrieve it when necessary and with a previous authorization check.
Also, pages such as Archive.org, WayBackMachine, or the Google cache, may pose a security problem when the cached files contain sensitive information and were not adequately protected in previous versions of the application. So, it is important to not allow the caching of that kind of documents.