Sensitive Data Exposure9:00 with Jared Smith
This vulnerability allows an attacker to access sensitive data such as credit cards, tax IDs, authentication credentials, etc to conduct credit card fraud, identity theft, or other crimes. Losing such data can cause severe business impact and damage to the reputation. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.
/r/crypto, List of books on cryptography for further learning
Sensitive data exposure bounties discovered on GitHub
In the final video of this sage, we're discussing the number 3 vulnerability 0:00 in the OS top 10 of 2017, up from number 6 in 2013. 0:05 Sensitive data exposure, while difficult to exploit in most cases 0:07 if proper security controls are in place, can be extremely impactful if it occurs. 0:13 The world's biggest data breaching are often result in unsecured sensitive data. 0:17 Exposure to this data often occurs when the apps don't use 0:22 easily applied security controls like SSL and password hashing. 0:25 Noble example of this breaches include Yahoo, 0:29 who's 1.5 million email accounts were compromise. 0:32 The compromised password were hashed, but 0:35 the passwords were hashed with a publicly known and insecure MD5 algorithm. 0:38 LinkedIn also faced a similar fate due to insecure hashing. 0:42 Deep Root Analytics, a data science firm, had over 198 million records 0:46 stolen after they left user records on an unsecurd, public Amazon S3 database. 0:51 In general since the data exposure allows an attacker to access sensitive data 0:57 like credit cards, tax IDs, authentication credentials, and 1:02 other data to commit credit card fraud, identity theft, or other malicious crimes. 1:05 If the state is compromised, a company's reputation can be severely tarnished, and 1:11 they may have to pay fees on compromised records. 1:15 In most cases, these breaches can severely impact normal business operations. 1:18 Sensitive data exposure usually occurs when a site does not use protections 1:23 such as SSL and TLS for all pages with sensitive data. 1:27 For example, if a site provides a log in page, this data must be protected with SSL 1:32 or TLS, to prevent attackers from stealing passwords, session tokens, or other data. 1:36 SSL and 1:42 TLS also protect against cases where attackers can monitor network traffic. 1:43 In the cases where users run unsecured public Wi-Fi connections. 1:47 Today, free services like Let's Encrypt provide valid SSL certificates easily and 1:51 for free. 1:56 Which you should definitely be using if you don't already have a secure site. 1:56 Beyond security, most search engines rank HHTPS websites secured with valid SSL and 2:00 TLS certificate higher, so why not? 2:06 Preventing sensitive data exposure goes beyond just using SSL and TLS. 2:09 All data must be encrypted at rest and in transit. 2:14 If encryption is only applied and data is sent, 2:17 but the data base of sensitive information is compromised, 2:20 that information can be used for malicious purposes. 2:23 Furthermore, information shouldn't be be stored unnecessarily. 2:25 When storing data is necessary, it should be stored with strong encryption 2:29 algorithms such as 1024 or 2048 bit keys or hashing for passwords. 2:33 Today, the recommended algorithms for hashing data are Bcrypt, Script, 2:38 Argon2, or PBKDF2. 2:43 Algorithm such as MD5 and SHA-1 are considered practically or 2:44 theoretically broken in 2017, based on the power of current computers. 2:49 Back in the front end of apps, autocomplete should be disable in 2:55 sensitive forms, since this is essentially caching sensitive information. 2:58 As you heard earlier, sensitive data exposure happens often in reality. 3:02 This is usually the result of unsecured pages and 3:06 the improper use of cryptographic algorithms. 3:08 Now, with that in mind, 3:11 let's observe these exact same issues in our own application. 3:12 In particular, our application uses HTTP to communicate with the server. 3:16 Which can be observed in the browser by noticing the lack of a lock icon in 3:22 the URL bar, as well as the warning. 3:26 However, we can make our server communicate over HTTPS by 3:28 requiring the HTTPS module within the main server file. 3:33 To do this, we first need to add the setup codes for application in the main file. 3:36 Here we used a stored key answer to the get inside our application directory. 4:06 In production, this certificate should be from a trusted 4:11 authority that distributes signed and trusted certificates, like Let's Encrypt. 4:14 After we add this configuration, 4:25 we just need to start our server with HTTPS enabled. 4:27 We can also do that in the main server file. 4:31 Beyond enabling HTTPS, 4:40 we also need to verify that our applications stores data correctly. 4:42 That means we should be using encryption for sensitive data storage in 4:46 the database, as well as other concerns, like password hashing. 4:50 Though we address password hashing in the session management video, 4:53 we have now addressed the storage of sensitive information. 4:56 On that note, let's look at how the user profile information is stored. 4:59 Which includes a date of birth and social security number, or 5:03 the equivalent in other countries. 5:06 The profile data is managed in a profiledao.js file in the data folder, 5:08 let's check it out. 5:13 Here, we can see that we don't encrypt the users date of birth or 5:14 social security number before storing it. 5:18 This is really not good, let's correct that. 5:20 To do this, we will use the nojs crypto module to encrypt this data, and 5:23 then we'll decrypt when it's fetched by the application from the database. 5:26 This module allows you to configure the algorithm used. 5:34 In our case, we'll choose the well known and 5:37 currently secure aes256 symmetric encryption algorithm. 5:39 Next, we'll also need a function to add more randomness, 5:55 using something called an initialization vector or IV. 5:58 Without the IV, this algorithm would be insecure, so 6:02 we have to ensure we add it when encrypting the data. 6:05 Here we've created a random salt for the IV. 6:29 Then use the PBKDF2 hashing algorithm to generate a random string 6:32 based on that salt. 6:35 The last of the helper functions we will need, lets us encrypt data and 6:37 decrypt data. 6:40 To do this, we will be using the configuration we set up earlier, 6:41 as well as the IV generation function. 6:44 Finally let's hook into where our application stores and 7:56 fetches the data and the user object. 7:59 Here we'll ensure the application does the actual encryption and 8:02 decryption, by calling the functions we made earlier. 8:05 To sum up, sensitive data exposure is a high impact, but 8:29 easily preventable vulnerability with basic security controls. 8:33 Like using HTTPS over HTTP, and trusted cryptographic algorithms, and 8:37 encrypting data at risk and in transit. 8:41 At this point, we've come a long way in protecting our applications from fatal 8:45 flaws, and we only have a few more OS vulnerabilities to go. 8:48 Join me in the next stage as we address issues such as misconfiguration, 8:52 using insecure components, and insufficient log-in and monitoring. 8:56
You need to sign up for Treehouse in order to download course files.Sign up