In this lesson,
we're going to discuss vulnerabilities associated
with improper headers in your web applications.
Now, the OWASP Secure Headers Project
describes different HTTP response headers
that your application can use to increase the security
of your application while placing its calls.
HTTP response headers are used to control
how a web server's going to operate in order
to increase its security during those operations.
If you leave the response headers configured
with your default settings,
you're going to have a very insecure web application
that can easily be exploited.
Therefore, it's important
to verify you have the proper header settings enabled
in order to protect against cross-site request forgeries,
cross-site scripting, downgrade attacks, cookie hijacking,
user impersonation, and clickjacking.
There are 10 different HTTP response headers
you should consider in your configurations.
These are HSTS, HPKP, X-Frame-Options,
X-Cross-Site-Scripting-Protection,
X-Content-Type-Options, Content-Security-Policy,
X-Permitted-Cross-Domain-Policies,
Referrer-Policy, Expect-CT and Feature-Policy.
First, we have HSTS,
which is the HTTP Strict Transport Security
web security policy, and this is going to be used
to protect your website against protocol downgrade attacks
and cookie hijacking.
By using HSTS, it's going to allow web servers
to declare that web browsers
or other complying user agents should only interact
with that server using secure HTTPS connections
and never through insecure HTTP protocols.
Second, we have the Public Key Pinning extension for HTTP,
also known as HPKP.
Now the HTTP Public Key Pinning is a security mechanism
which allows HTTPS websites to resist impersonation
by attackers using mis-issued
or otherwise fraudulent certificates.
The HTTPS web server is going to serve up a list
of public key hashes, and on subsequent connections,
clients can expect that server to use one
or more of those public keys in its certificate chain.
Deploying HPKP safely will require operational
and organizational maturity because there is a risk
that hosts can make themselves unavailable by pinning
to a set of public key hashes that become invalid.
Using HPKP, this can actually greatly reduce the risk
of an on path or man-in-the-middle attack,
and therefore, it's going to be very useful
to giving you a secure environment.
It can also help
with other false authentication problems too.
Third, we have the X-Frame-Options header.
Now, the X-Frame-Options header is used
to prevent clickjacking from occurring by declaring a policy
that communications are only allowed from the host
to a client browser directly, without allowing frames
to be displayed inside of another webpage.
Fourth,
we have the X-Cross-Site-Scripting-Protection header.
This header is used
to enable the cross-site scripting filter
in the web browser, and provides a method
to sanitize the page and report the violations
if a cross-site scripting attack is attempted
by the browser.
Fifth, we have the X-Content-Type-Options header.
The X-Content-Type-Options header setting is going
to be used to prevent the browser from interpreting files
as something other than what they're declared by
as the content type in the HTTP header.
Essentially, this header is used to dictate the content type
that the page should interpret everything as
and prevent the threat actor
from tricking the browser into processing the wrong type
of file or content.
Sixth, we have the Content-Security-Policy header or CSP.
Now, the Content-Security-Policy header
requires careful tuning and precise definitions
of its policy.
If you enable CSP,
it has significant impact on the way browsers render pages
such as disabling inline JavaScript by default,
so JavaScript has to be explicitly allowed
in the policy if you're going to run it.
The Content-Security-Policy header is able
to prevent a wide range of attacks, though,
including cross-site scripting
and other cross-site injections.
Seventh,
we have the X-Permitted-Cross-Domain-Policies header.
The X-Permitted-Cross-Domain-Policies header
sends a cross-domain policy file as an XML document
to the web client,
and then specifies if the browser has permission
to handle data across multiple domains or not.
When clients request content
hosted on a particular source domain
and that content makes request directed towards a domain
other than its own, the remote domain needs
to be inside the hosted cross-domain policy file
that grants access to that source domain
and allows that client to continue that transaction.
Normally, a meta-policy is going
to be declared in the master policy file,
but for those who can't write to the root directory,
they can also use a declare a meta-policy
using this X-Permitted-Cross-Domain-Policies
HTTP response header instead.
Eighth, we have the Referrer-Policy header.
The Referrer-Policy header is going to govern
which referrer information is sent in the referrer header
and should be included in the request being made.
For example, the Referrer-Policy could contain the value
of the same origin, which tells the browser
that the same-site-origins are authorized,
but cross-origin requests are not.
Ninth, we have the Expect-CT header.
Now, the Expect-CT header is used by a server
to indicate that browsers should evaluate connections
to the host omitting the header
for the Certificate Transparency Compliance Method.
Now, Certificate Transparency is an open framework
for monitoring digital certificates.
Domain owners may find it useful
to monitor certificate issuance for their domain
and use that to detect misuse certificates.
Prior to Certificate Transparency,
There is not an efficient way to get a comprehensive list
of all the certificates issued to your domain,
and so enabling CT is something useful.
10th, we have the Feature-Policy header.
The Feature-Policy header allows developers
to selectively enable and disable the use
of various browser features and APIs.
For example, if you want to control access
to the accelerometer or gyroscope in a mobile device
using its web browser,
you can do that using the Feature-Policy header.
One useful feature to enable for a secure web application
might be the geolocation feature
using the Feature-Policy header.
This would allow you to ensure the user is located
within a specific geographical area as part
of your authentication process, for example.
So in summary,
if you're working as a developer for web applications,
it's important for you to review the different HTTP headers
and response options that are available to you
to secure your web applications
and minimize their vulnerabilities.