21
By: Nileshwari Desai Roll No: A 216

Cookie replay attack unit wise presentation

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Cookie replay attack  unit wise presentation

By: Nileshwari Desai

Roll No: A 216

Page 2: Cookie replay attack  unit wise presentation

INTRODUCTION

WHAT IS A COOKIE

DIFFERENT TYPES OF COOKIES

WHAT IS A COOKIE REPLAY ATTACK

HOW IT WORKS?

COOKIE IN-SECURITY PERSPECTIVE

CONCLUSION

REFERNCES

Page 3: Cookie replay attack  unit wise presentation

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.

Page 4: Cookie replay attack  unit wise presentation

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).

Page 5: Cookie replay attack  unit wise presentation

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.

Page 6: Cookie replay attack  unit wise presentation

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.

Page 7: Cookie replay attack  unit wise presentation

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.

Page 8: Cookie replay attack  unit wise presentation

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.

Page 9: Cookie replay attack  unit wise presentation

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.

Page 10: Cookie replay attack  unit wise presentation

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.

Page 11: Cookie replay attack  unit wise presentation

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.

Page 12: Cookie replay attack  unit wise presentation

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.

Page 13: Cookie replay attack  unit wise presentation

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.

Page 14: Cookie replay attack  unit wise presentation

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.

Page 15: Cookie replay attack  unit wise presentation

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.

Page 16: Cookie replay attack  unit wise presentation

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.

Page 17: Cookie replay attack  unit wise presentation

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.

Page 18: Cookie replay attack  unit wise presentation

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

Page 19: Cookie replay attack  unit wise presentation

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.

Page 20: Cookie replay attack  unit wise presentation

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.

Page 21: Cookie replay attack  unit wise presentation