Cookie replay attack unit wise presentation

569 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
569
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Cookie replay attack unit wise presentation

  1. 1. By: Nileshwari Desai Roll No: A 216
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.

×