Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
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.
Further Reading:
OWASP Sensitive Data Exposure
World’s Biggest Data Breaches
Let’s Encrypt, which provides free trusted HTTPS certificates
Node.js Crypto module
Node.js HTTPS module
/r/crypto, List of books on cryptography for further learning
Cryptography Wiki
Sensitive data exposure bounties discovered on GitHub
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
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 upYou need to sign up for Treehouse in order to set up Workspace
Sign up