Web applications are storing and transmitting more sensitive data than ever before. From banks, hospitals, and government agencies to gourmet delis, hair salons, and comic book stores: all rely on software to operate their businesses. The challenge to the engineers developing this software is keeping this sensitive information protected from an ever-increasing number of threats. This frequently means cryptography.
Cryptography is a collection of mathematical disciplines and techniques used to protect the secrecy and integrity of sensitive data. The broad science of cryptography aims to offer mitigations to common problems encountered during the transmission and storage of data.
Although cryptography does not eliminate security issues, it does make them more manageable by reducing the task of protecting a large amount of data to a matter of protecting a relatively small key.
Note, however, cryptography does not imply secure software. Data protection is not the only piece needed in order to build secure software. Cryptography is only useful if the rest of the system is sufficiently secure from attackers.
Sensitive data exposure is a widespread issue and spans a range of topics including data encryption, password storage, and access control mechanisms. This lesson will provide actionable guidelines to help protect your systems against the risks associated with transmitting and storing sensitive data.
Handling Sensitive Data Securely
Before implementing safeguards to protect your sensitive data, it is critical to first understand exactly which data you are trying to protect. Information such as health records, credentials, banking details, social security numbers, and personally identifiable information all require extra operational and technical safeguards.
- Encrypt, encrypt, encrypt. If you must transmit and store sensitive data, always employ strong encryption mechanisms in transit and at rest. The OWASP Transport Layer Protection Cheat Sheet and the OWASP Cryptographic Storage Cheat Sheet are excellent references when considering the transmission and storage of sensitive data in your application.
- Correct security misconfigurations. Often, a security misconfiguration in your applications technology stack can cause the exposure of sensitive data. Verify that all default credentials and accounts are changed, turn debugging mode off in production, and enforce bulletproof access controls.
- Store passwords securely. If your application requires users to authenticate, you need to consider the security around how passwords are stored. Always force passwords through an irreversible, one-way adaptive function with a strong work factor, and never store them in plaintext. The OWASP Password Storage Cheatsheet provides detailed guidelines regarding secure password storage.
- Evaluate the need to store sensitive data. Is there a valid business need to collect and store sensitive data? Often it is not necessary to store the original value of sensitive fields such as social security numbers or credit card numbers. If a reference to the data is needed, tokenization and one-way anonymization techniques can be used to reduce the risk of this data ever being exposed in plaintext formats.
- Audit your data. Perform internal inventory audits of your data. Knowing where to focus your security efforts and understanding the consequences of exposing this data is an important piece of any security program.
Grammarly Mixup
Browser extensions are an often overlooked source of severe vulnerabilities. When the appropriate permissions are granted, browser extensions can have the ability to read any webpage you visit, any form field you fill in, cookie values, and loads of other interesting bits. In late 2017, the infamous Google Project Zero researcher Tavis Ormandy dropped a bomb on the extremely popular grammar and spell checking extension called Grammarly. In typical Tavis fashion, he sent out a somewhat cryptic Tweet notifying the public of the issue after it was patched.
While the issue was not maliciously exploited to the knowledge of Grammarly, the problem was critical, to say the least. Tavis was able to write a very simple proof-of-concept attack that allowed an attacker to steal the authentication token used by the Grammarly extension by hosting a simple JavaScript function that could be hosted just about anywhere. The core of the issue is that this particular token also served as the session identifier for grammarly.com, allowing the attacker to easily authenticate as the victim to the web application, which hosts saved documents, history, and sensitive logs.
Source: https://thehackernews.com/2018/02/grammar-checking-software.html
RATIOS 