2. INTRODUCTION
WHAT IS A COOKIE
DIFFERENT TYPES OF COOKIES
WHAT IS A COOKIE REPLAY ATTACK
HOW IT WORKS?
COOKIE IN-SECURITY PERSPECTIVE
CONCLUSION
REFERNCES
3. Internet security is not one to be taken lightly. There is
a saying that Internet Security is a trade-off between
security and usability. And that’s true for the most
part, but luckily protection against replay attacks does
not hinder usability—it’s almost completely
transparent to the end users.
4. A cookie, also known as an HTTP cookie, web cookie,
or browser cookie, is a small piece of data sent from a
website and stored in a user's web browser while the user is
browsing that website.
Every time the user loads the website, the browser sends
the cookie back to the server to notify the website of the
user's previous activity.
Cookies were designed to be a reliable mechanism for
websites to remember state ful information (such as items
in a shopping cart) or to record the user's browsing activity
(including clicking particular buttons, logging in, or
recording which pages were visited by the user as far back
as months or years ago).
5. What it is?
Small piece of information stored in client system.
Transferred back and forth between Server and
browser.
Keeps the state of the session active.
6. A user's session cookie (also known as an in-memory
cookie or transient cookie) for a website exists in
temporary memory only while the user is reading and
navigating the website. When an expiry date or validity
interval is not set at cookie creation time, a session
cookie is created.
Web browsers normally delete session cookies when
the user closes the browser.
7. A persistent cookie will outlast user sessions. If a
persistent cookie has its Max-Age set to 1 year (for
example), then, during that year, the initial value set in
that cookie would be sent back to the server every time
the user visited the server.
This could be used to record a vital piece of
information such as how the user initially came to this
website. For this reason, persistent cookies are also
called tracking cookies.
8. A secure cookie has the secure attribute enabled and is
only used via HTTPS, ensuring that the cookie is
always encrypted when transmitting from client to
server.
This makes the cookie less likely to be exposed to
cookie theft via eavesdropping. In addition to that, all
cookies are subject to browser's same-origin policy.
9. The Http Only attribute is supported by most modern
browsers. On a supported browser, an Http Only
session cookie will be used only when transmitting
HTTP (or HTTPS) requests, thus restricting access
from other, non-HTTP APIs (such as JavaScript).
This restriction mitigates but does not eliminate the
threat of session cookie theft via cross-site
scripting (XSS). This feature applies only to session-
management cookies, and not other browser cookies.
10. First-party cookies are cookies that belong to the same domain that is
shown in the browser's address bar
Third-party cookies are cookies that belong to domains different from
the one shown in the address bar. Web pages can feature content from
third-party domains, which opens up the potential for tracking the
user's browsing history.
As an example, suppose a user visits www.example1.com. This web site
contains an advert from ad.foxytracking.com, which, when
downloaded, sets a cookie belonging to the adverts' domain
(ad.foxytracking.com). Then, the user visits another
website, www.example2.com, which also contains an advert
from ad.foxytracking.com, and which also sets a cookie belonging to
that domain (ad.foxytracking.com). Eventually, both of these cookies
will be sent to the advertiser when loading their ads or visiting their
website. The advertiser can then use these cookies to build up a
browsing history of the user across all the websites that have ads from
this advertiser.
11. A "super cookie" is a cookie with an origin of a Top-Level
Domain (such as .com) or a Public Suffix (such as .co.in). It
is important that super cookies are blocked by browsers,
due to the security holes they introduce. If unblocked, an
attacker in control of a malicious website could set a super
cookie and potentially disrupt or impersonate legitimate
user requests to another website that shares the same Top-
Level Domain or Public Suffix as the malicious website.
For example, a super cookie with an origin of .com, could
maliciously affect a request made to example.com, even if
the cookie did not originate from example.com. This can be
used to fake logins or change user information.
12. Some cookies are automatically recreated after a user
has deleted them; these are called zombie cookies.
This is accomplished by a script storing the content of
the cookie in some other locations, such as the local
storage available to Flash content, HTML5 storages
and other client side mechanisms, and then recreating
the cookie from backup stores when the cookie's
absence is detected.
13. Essentially a security breach whereby someone poses
as someone else using some unique piece of data the
user supplied/was issued to/from the Web server. It’s
kind of similar to a man-in-the-middle attack.
Replay attacks are often one thing that programmers
forget to protect against. This really is quite a worry
since I want my identity to be safe online and I’m sure
you do, too.
14. Browser requests a page on server.
Then server sends back a cookie with the requested
page to the browser.
The browser sends the cookie to the server with
subsequent requests.
Point to be noted that the user will be identified by
the server exclusively on the cookie that is returned.
15. 1. John logs into example.org.
2. Server issues John a cookie with value of 12345.
3. John revisits example.org again and is logged in.
4. Evil Joe looked at the request and steals the cookie.
5. Joe visits example.org which logs him in as John.
16. Due to the very nature of the attack it isn’t possible to
100% protect against it, it’s inherently insecure. But
there are ways to increase the security, and that’s to
add another step after (3) above:
Server reissues John a cookie with value of 67891.
It’s called token regeneration. We have recognized that
John has a valid cookie, logged the user in, removed
their old cookie and recreate a new one that no one
else should know. Even if Joe had the old cookie it’s no
longer valid and has to perform the same actions as (4)
in the original way.
17. Another method is to add some kind of time
restriction, so only make the cookie valid for a certain
amount of days. So if Joe happens to stumble across
the cookie after a month he should no longer be able
to login as John.
Another to add in which browser John is using, the
chances of John using exactly the same as Joe is
unlikely.
18. Cookie related attacks
Cookie Poisoning
→Tampering or changing the cookie
→Relatively difficult to construct the cookie similar
to the original one
→The difficulty depends on the complexity of
cookie generation mechanism
Cookie Replay
→Simply reuse a valid cookie
→Relatively simple to get a valid cookie through
sniffing
19. Use HTTPs while browsing (If secure cookie is
implemented)- First level defense in depth.
Cookie Life time- Be strict in giving age to cookie.
Secure Cryptography: Don’t innovate, use existing
best proven.
Persistent Cookie- Avoid it.
20. We studied how basically a cookie works and also
explored different types of cookies. The replay attack
was discussed and the different types of cookie replay
attacks were acknowledged . Also the preventive
measures for the attack were discussed.
