Leakage of Cookie with Sensitive Data
Overview
In this module I will show you how the cookie with sensitive
data can leak over insecure channels. You will not only learn how this attack
works, but you will also learn how to prevent this attack from happening. First
of all, I will describe the difference between HTTP and HTTPS. When browser is
communicating with the web application, then the communication can go over HTTP
or HTTPS, and we need to understand the difference between them. Then I will
discuss one of the optional attributes in set cookie header, secure attribute.
This attribute is used to protect the confidentiality of our sensitive cookies.
And finally I will show you demo, and in the demo you will see how the leakage
of cookie, with sensitive data, can happen in reality.
HTTP vs. HTTPS
Let me first describe the difference between HTTP and HTTPS.
HTTP is insecure protocol, this is just plain text, there is no security here.
HTTPS is very much different, HTTPS is secure one, HTTPS guarantees
confidentiality, integrity, and authentication.
Secure Attribute
It turns out that we can specify an optional secure
attribute in the set cookie header. If this attribute is not specified in set
cookie header, then the cookie will be sent over insecure HTTP and secure
HTTPS. However, when this attribute is specified in set cookie header, then we
are guaranteed that this cookie will be sent only over secure HTTPS.
Demo
Is our web application vulnerable to the leakage of cookie
with sensitive data over insecure channel or not? Let's check it out. Here is
my web application, let me login first. Right now I am authenticated. Let's see
what cookies are used in this web application. For this purpose, I will use
cookies manager, because it allows me easily to read and modify cookies. I'm
using here cookies manager plus this is just an exemplary cookies manager you
can use to play with the cookies. As you can see, there is a cookie named
PHPSESSID, it stores session ID of the user, so this is a really sensitive
cookie. Let's see the details related to this cookie. This cookie can be sent
for any type of connection; it actually means that this cookie can be sent
either via insecure HTTP or via secure HTTPS. In other words, secure attribute
has not been set for this cookie. This is what browser knows about this cookie.
Browser knows this information, because there must have been set cookie header
with this information. Let's check it out. Let me analyze, right now, the
history of the communication. In my environment the whole traffic going out
from the browser goes through the proxy, before it reaches web application,
that's why I'm able to see this traffic in the history of the proxy. I'm using
here proxy functionality in Burp Suite, which is an integrated platform for web
application security testing. Here is my login request and here the response.
What you can see in the response if set cookie header, give the name of the
cookie, and value of the cookie. There is nothing more, so you immediately see
that secure attribute has not been set for this cookie and this cookie can leak
over insecure channel. Let me now show you that indeed it can happen. What I'm
going to do right now, is sending the request over HTTP to some arbitrary
resource. It really doesn't matter if this resource exists or not. What really
matters are whether the cookie with sensitive data is appended to this insecure
HTTP request or not. I need to see whether the cookies appended to the request
or not. So I need to somehow intercept this request. For this purpose, I will
use interceptor in Burp Suite proxy. So I will just intercept the outgoing
request from the browser to the web application. Let's do it. As you can see,
the request goes out over insecure HTTP and our sensitive cookie, with session
ID, is appended to this request. So now you see how the leakage of sensitive
cookie over insecure channel looks like in reality. Finally, let me show you
how the behavior is very much different when secure attribute is set for a
cookie. What I'm going to do right now is go into cookies manager, going back
to the details of the cookie, and now I will mark this cookie with secure
attribute. What I'm doing right now is simulating set cookie header with secure
attribute. Let me now save it and repeat the steps. Let's send the request over
HTTP to arbitrary source. Now let me turn on the interceptor and send the
request. Again, the request is intercepted, the request goes over insecure
HTTP, but now the cookie has not been appended to this request. The reason is
that, the cookie has been marked with secure attribute and this secure
attribute means don't send this cookie over insecure HTTP. So in this
situation, there is no leakage of sensitive cookie over insecure channel.
Summary
Let me summarize this module. You have learned that HTTP is
insecure protocol, this is just plain text, there is no security here. On the
contrary, HTTPS is secure one. It guarantees confidentiality, integrity, and
authentication. We don't want our cookies with sensitive data to be disclosed
over insecure HTTP. That's why we should mark our sensitive cookies with secure
attributes. Then we are guaranteed that these cookies will only be sent over
secure HTTPS.
Cookie Hijacking
Overview
In this module I will show you how the attacker can remotely
hijack sensitive cookies of the user. First of all, I will introduce you to one
of the most prevalent and dangerous attacks, cross-site scripting attack, in
short, XSS. When this attack is launched, then the attacker wants to steal
session ID of the user. That's why HTTP only attribute was introduced to
prevent it from happening. And it will be discussed in the next section.
Finally, I will show you demo and in the demo you will see how the attacker can
remotely hijack sensitive cookies of the user.
Introduction to XSS Attack
Let me introduce you very briefly to cross-site scripting
attack. Let's assume that attackers control data, is a reflected backend
response, and this response comes to user. If this data is, for example, xyz,
then nothing bad will happen, this is just a string. However, if the attacker
can specify arbitrary data, that will be reflected back in response without any
modifications, then the consequences can be very severe. Let's assume that attackers
control script, is reflected back in response without any modifications. Then
the attacker can change the behavior of the page and this is very dangerous. It
actually allows the attacker to do arbitrary scripting, that's why it's so
dangerous. For example, the attacker can still use his cookie with session ID.
So right now I believe you understand the why this attack is so dangerous.
Http Only Attribute
We don't want the attacker to be able to steal our sensitive
cookies when XSS attack is launched. That's why HTTP only attribute was
introduced. If this attribute is not specified in set cookie header, then the
cross-site scripting attack can be used to remotely steal sensitive cookies
from the user. However, if this attribute is specified in set cookie header,
then XSS attack can no longer be used to remotely hijack sensitive cookies of
the user.
Demo
It's time for demo right now. The question is whether XSS
attack can be used to steal remotely our sensitive cookies or not? Let's check
it out. Let me first show you that cross-site scripting attack is possible
here. There is search functionality and you can use this functionality to find
out whether a given product is available in the store or not. Let's check if a
product, xyz, is available in the store. As you can see, this product is not
available in the store, but what's important from our point of view is that the
data we entered is now reflected back in response. Xyz is not dangerous, the
question is, whether arbitrary data is reflected back in response without
modifications or not. If it is reflected back without modifications, then the
attacker can enter a script this script becomes reflected back in response. And
the attacker can do arbitrary scripting. So let's check if this is possible here.
Let me show you first the list of scripts I'm going to use throughout this
demo. The first one is just a proof of concept. I want to prove that cross-site
scripting attack is possible. This is just an alert; we have a message XSS. The
second one is the actual attack, because what the attacker wants to do,
actually, is stealing cookies of the user and sending those cookies to the
attackers control domain. So let me first focus on the proof of concept and
then I will discuss the actual attack. So let's prove that cross-site scripting
attack is possible here so let me copy this and paste it here. What you can see
is that alert with a message XSS is executed, so we proved that cross-site
scripting attack is possible. The question is, how is that script delivered
from the attacker to the user? Because the attacker has to deliver this script
somehow to the user so that this script is finally executed within the context
of the user. As you can see, this script is sent in the URL as a value of
searching a parameter. So it's enough for the attacker to send this link to the
victim and once this link is clicked by the victim, the script is automatically
executed. Let me show you that indeed it can happen, so I'm going to copy this
link, I will paste it here and what you can see is that indeed it's enough to
send a link to the user and the script is automatically triggered. So right now
you know how cross-site scripting attack works, you know how to deliver the
script to the user. Now let's do something more interesting from an attacker’s
point of view, let's steal users’ cookies. As you can see the user is
authenticated, so if I steal user’s cookie with session ID I can impersonate a
user. Let me go again to my scripts and let me focus on the actual attack. This
script reads cookies of the user and sends those cookies in the URL to the
attackers control domain. So this is actually what the attacker wants to
achieve. So let me now show you that indeed it works, so I'm going to copy this
script and I will paste this script here. Right now everything happens in the
background, because our script is just used to fetch the cookies of the user
and send these cookies in the URL to the attacker's controlled domain. That's
why nothing is visible here, everything happens in the background, let me show
you that indeed the cookies were sent to the attacker’s domain. Keep in mind
that in my environment the whole traffic is sent through the proxy so let me
find out the request to the attacker's control domain. Here it is, as you can
see, PHPSESSID, the cookie with session ID of the user is sent in the URL to
the attackers control domain. It proves that indeed the attacker can use
cross-site scripting attack to steal sensitive cookies of the user. This is
possible because our cookie, with session ID, has not been marked with HTTP
only attribute. Let me now show you how the behavior is very much different
when the cookie is marked with HTTP only attribute. So what I'm going to do
right now is go into cookies manager, let me go to the details of the cookie,
and now I will mark this cookie with HTTP only attribute. So what I'm actually
doing right now is simulating set cookie header with HTTP only attribute. So
let me save it and repeat the steps. So let me launch this attack again, so let
me copy this, paste it here, again everything happened in the background, so
let's go to the history of the proxy. As you can see, here is the request to
attacker's control domain, but now the cookie has not been sent in the URL,
because the cookie is marked with HTTP only attribute. That's why XSS attack
cannot be used to read this cookie so right now you see why it is so important
to mark our sensitive cookies with HTTP only attribute.
Summary
Let me summarize this module. I have introduced you to one
of the most prevalent and dangerous attacks, cross-site scripting. You have
learned that this attack can be used to remotely steal sensitive cookies of the
user. Make sure your sensitive cookies are marked with HTTP only attribute,
then XSS attack can no longer be used to remotely steal sensitive cookies of
the user.
Weaknesses In Cookie Lifecycle
Overview
In this module I will discuss weaknesses in cookie
lifecycle. First I will discuss the importance of regeneration, you will learn
why it is so important to regenerate sensitive cookies. Then I will show you a
demo and in the demo you will see how the attacker can impersonate a user when
cookie with session ID is not regenerated at the time of authentication. Then
you will learn about server-side invalidation and why it is so important
subject. I will discuss the significant difference between invalidation of
cookie with session ID on the server side and deletion of this sensitive cookie
from user’s browser. Finally, I will show you another demo in this demo you
will see how to get access to the account of the logged out user, when cookie
with session ID is not invalidated on the server side at the time of logging
out.
Importance of Regeneration
Let me now discuss the importance of regeneration. Here is
the story. The user is logged out and his session ID, we just stored in the
cookie, is, for example, abs. This is not authenticated session ID, because the
user is logged out. Now the attacker comes and learns session ID of the user.
At this moment, it is useless for the attacker because the user is not
authenticated yet. Let's continue the story. User logs in and his session ID is
still abs. Now this is authenticated session ID, because the user is logged in.
The problem is, that right now the authenticated and non-authenticated session
IDs are the same. That's why there's non-authenticated session ID learned by an
attacker at point number two, is no longer useless for the attacker. Now it can
be used by the attacker to impersonate a user. Keep in mind that in reality
session ID is long and unpredictable, otherwise, it would be very easy for the
attacker to guess session ID of the user. However, he for simplicity of
description, it is just abs. What should be done here to prevent this attack
from happening is a regeneration of cookie with session ID. It should happen at
point number three, in other words, the session ID should be returned to a user
at the time of authentication. Then authenticated session ID is different than
non-authenticated session ID. That's why none authenticated session ID can no
longer be used to get access to the users account. So we have to remember that
sensitive cookies should be regenerated when we go from non-authenticated to
authenticated state.
Demo
A cookie with session ID regenerated in my web application,
when I go from non-authenticated to authenticated state. In other words, is it
possible to impersonate a user as a result of a weakness in login
functionality? Let's check it out. Let me login first. Before I press login
button, I will turn on the interceptor to intercept the outgoing request from
my browser. Now interceptor is turned on. Let me send this request. As you can
see, the request becomes intercepted. What I'm going to do next is sending this
request to repeater. Repeater is part of Burp Suite, it can be used to resend
the selected request. Once more, in repeater the request and response are
presented on one screen and that's the reason why I use repeater here. If I
have request and response on one screen, then I can easily check if my
sensitive cookie has been regenerated or not. What you can see on the left side
is login request. Let me now click GO to send this request. The response for
this request is presented on the right side. Session ID is stored in the cookie
names PHPSESSID. On the left side there is a cookie with non-authenticated
session ID. On the right side, there is a cookie with authenticated session ID.
As you can see, the value of both cookies is the same. In other words, cookie
with session ID has not been regenerated at the time of authentication. That's
why the attacker who learned the value of cookie with non-authenticated session
ID, can now impersonate the user. So I believe that right now you understand
why sensitive cookies should be regenerated.
Server-side Invalidation
Let me now discuss server-side invalidation. Here is the
story. User logs out and the cookie with authenticated session ID is deleted
from users browser. The question is, is it enough? Shall we do something more?
Let's assume that there was no server-side invalidation at the time of logging
out. In other words, the cookie we've authenticated session ID was not
invalidated on the server-side. Then it's still possible to get access to the
user's account, because from the point of view of the server the user is still
logged in. So if the attacker learned the value of user's session ID, when user
was logged in, then the attacker can still get access to user's account. Keep
in mind that it's not important what happens on the client side, in other
words, it doesn't matter that the cookie we've authenticated session ID was
deleted from user's browser. What matters here, is that this sensitive cookie
was not invalidated on the server-side at the time of logging out. Now I
believe you understand why server-side invalidation is so important subject.
Demo
Is my cookie with session Id invalidated on the server-side
at the time of logging out? In other words, is it possible to get access to the
account of the logged out user as a result of a weakness in logout
functionality? Let's check it out. Right now I am authenticated, let's see what
cookies are used here. For this purpose, I will use cookies manager. As you can
see, there is a cookie named PHPSESSID, it stores session ID of the user. This
is authenticated session ID, because right now I am logged in. What I'm going
to show you in this demo is that I am able to get access to the account of the
logged out user as a result of a weakness in logged out functionality. So
before logging out, I will copy the value of authenticated session ID and I
will paste it to this file. In a minute I will show you the corresponding
non-authenticated session ID. That's why I have this file, for the purpose of
comparison. Let me now logout. Right now I am logged out, let me show you what
has changed in terms of cookie processing. Let's go to cookies manager. There
is a cookie with session ID, but right now I am logged out. So this is
non-authenticated session ID. Let me copy this value and paste it to my file.
As you can see, the authenticated session ID was deleted, it was replaced by
non-authenticated session ID. However, it's not important what happened on the
browser side, it's important what happened on the server-side. In other words,
the question is whether cookie with authenticated session ID was invalidated on
the server-side at the time of logging out or not. Let's check it out. I will
copy the value of authenticated session ID to my cookies manager. Let me save
it now and refresh the page. As you can see, I am authenticated. It proves that
the authenticated session ID was not invalidated on the server-side at the time
of logging out. So the user seems to be logged out from the point of view of
the browser, but from the point of view of the server, the user is still logged
in. That's why we should always remember about server-side invalidation.
Summary
Let me summarize this module. You learned why regeneration
of cookies with sensitive data is so important subject. It was demonstrated how
the attacker can impersonate a user when cookie with session ID is not
regenerated at the time of authentication. You also learned about server-side
invalidation, I discussed the significant difference between invalidation of
cookie with session ID on the server-side and deletion of this sensitive cookie
from users browser. Finally I demonstrated how the attacker can get access to
the account of the logged out user, when cookie with session ID is not
invalidated on the server-side at the time of logging out.
Underestimated
Risk: XSS via Cookie
Overview
In this module I will discuss one of the most underestimated
cookie attacks, XSS via cookie. I introduced XSS attack in one of the previous
modules, in this module I will focus on XSS via cookie. In other words, XSS
attack, which is executed as a result of insecure cookie processing. Many
people claim that this attack can only be executed locally, because in their
opinion the attacker cannot set a cookie remotely in a cookie jar of the user.
But this is not true and I will show you in this module how the attacker can
use cross origin exploitation to launch XSS via a cookie remotely. I will also
show you a demo and in the demo you will see how cross origin exploitation
works in practice. Finally, I will discuss how to prevent XSS via cookie from
happening.
XSS via Cookie
XSS via cookie is executed when attackers controlled script
is taken from a cookie and it is reflected back in response without any
modifications. As I mentioned in the introductory part of this module, XSS via
cookie is not only about local exploitation. The attacker can set a cookie
remotely in the cookie jar of the user and then when the domain is visited by
the user, XSS via cookie is automatically executed. Let's assume that XSS via
cookie is possible on domain a. example. com. And the attacker didn't find a
vulnerability on this domain that could be used to set a cookie in user's
browser. It looks like the attacker cannot launch this attack remotely, because
the attacker doesn't know how to set a cookie in a cookie jar of the user. It
turns out, however, that the attacker can go beyond domain a. example. com to
set a cookie remotely in user's browser. And cross origin exploitation can be
used for this purpose. Let me now present the high level overview of cross
origin exploitation. Let's assume that XSS attack is possible on domain b.
example. com. As a result of this attack, the attacker can set a cookie
remotely in a cookie jar of the user. Once it is done, the user visits domain
a. example. com and then XSS via cookie is automatically executed on this
domain. As I mentioned, this is high level overview of cross origin
exploitation. The details will be discussed in the next section.
Cross-origin Exploitation
Let me now present step-by-step how cross origin
exploitation can be used by the attacker to launch XSS via cookie remotely.
Let's assume first that XSS attack is possible on domain b. example. com. As a
result of this attack, the attacker can set a cookie remotely in the cookie jar
of the user. The cookie can be set with an optional domain attribute. If the
value of this attribute is. example. com then user's browser knows that this
cookie should be sent to domain example. com and all subdomains of example.
com. That's why this cookie will be sent to domain a. example. com. Let's
assume now that XSS via cookie is possible on domain a. example. com. When this
domain is visited by the user, the cookie that has been set by the attacker, is
appended to the outgoing request to this domain. And finally XSS via cookie is
executed. As you can see, XSS attack on one subdomain of example. com, can be
used to launch remotely XSS via cookie on another subdomain of example. com.
That's why we are talking here about cross origin exploitation.
Demo
It's time for demo, let me show you how cross origin
exploitation works in practice. I will demonstrate how the attacker can use XSS
attack on domain b. example. com. To launch remotely XSS via cookie on domain
a. example. com, first the attacker will launch XSS attack on domain b.
example. com. In order to set a cookie remotely in the victims browser, let me
show the script that will be used in this attack. This script is used to set a
cookie named language in a cookie jar of the victim. The cookie's set with an
optional domain attribute and the value of this attribute is. example. com.
That's why this cookie will be sent to domain a. example. com, when this domain
is visited by the victim. Once more, this cookie includes a script which
displays alert with a message XSS. And this script is included in this cookie,
because finally the attacker wants to launch XSS via cookie on domain a.
example. com. But first, the attacker has to set this cookie remotely in
victim's browser. In order to do it, the attacker will use this script in XSS
attack on domain b. example. com. Let me show you how it works. I will copy
this script and I will paste it as a value of question parameter. When this URL
is visited by the victim, the value of question parameter is reflected back in
response without any modifications and the script is executed. You don't see
anything here, because this script was executed in the background. Let me now
go to cookies manager and show you that the cookie was set in victim's browser
as a result of XSS attack on domain b. example. com. As you can see, indeed it
happened. Now domain a. example. com will be visited by the victim. Then the
cookie is appended to the outgoing request to this domain, the value of this
cookie is reflected back in response without any modifications. And finally,
XSS via cookie is executed on domain a. example. com. Now I believe that you
understand how XSS attack on one subdomain of example. com can be used to
launch remotely XSS via cookie on another subdomain of example. com. Finally
keep in mind, that the attacker can use an arbitrary script, for example a
script that can be used to steal the session ID of the user. And this script
was presented in one of the previous modules. However, here just for the
simplicity of presentation, I used a simple script displaying alert with a
message XSS.
Fixing the Problem
Let me now show you how to prevent XSS via cookie from
happening. If attackers controlled script is taken from a cookie, and it is
reflected back in response without any modifications, then the script is
executed. This is how XSS via cookie works and the reason why this attack works
here is that special characters, less than character, and greater than
character, are reflected back in response without any modifications. These
characters are special, because the attacker can use them to create a script
tag and then the attacker can do arbitrary scripting. If you want to prevent
this attack from happening, then we have to sanitize these special characters.
Let me now show you how the sanitized version of this script looks like. As you
can see, less than character has been replaced by ampersand LT;. And the
greater than character has been replaced by ampersand GT;. Now from the
browser's point of view there is no script tag, so the attacker's script will
not be executed in user's browser. Ampersand LT; means display less than
character, ampersand GT; means display greater than character. That's why the
browser will display the following string of characters as a result of
sanitization. Now I believe that you understand why sanitization is so
important. When there is no sanitization the attacker's script is executed in
user's browser. When sanitization is implemented, the script is not executed in
user's browser. Then the script is just displayed as a string of characters and
you don't have to do this sanitization manually, there are different functions
in different programming languages that will do this sanitization for you.
Summary
Let me summarize this module. XSS via cookie is not only
about local exploitation, the attacker can set a cookie remotely in a cookie
jar of the user and then when the domain is visited by the user, XSS via cookie
is automatically executed. The attacker can use cross origin exploitation to
launch XSS via cookie remotely. It was demonstrated how XSS attack on one
subdomain can be used to launch remotely XSS via cookie on another subdomain.
Finally, it was presented how sanitization of special characters can be used to
prevent XSS via cookie from happening.
0 Comments