1 / 27

Cookies

Cookies. COEN 351 E-commerce Security. Client / Session Identification. HTTP does not maintain state. State Information can be passed using: HTTP Headers Client IP Address HTTP User Login FAT URLs Cookies. Client / Session Identification: HTTP Header. HTTP Header fields: “From”

mpak
Télécharger la présentation

Cookies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Cookies COEN 351 E-commerce Security

  2. Client / Session Identification • HTTP does not maintain state. • State Information can be passed using: • HTTP Headers • Client IP Address • HTTP User Login • FAT URLs • Cookies

  3. Client / Session Identification:HTTP Header • HTTP Header fields: • “From” • User’s email address, request. • Could be used by all browsers, but are only used for web-bots gathering data. • “User-Agent” • User’s browser software, request. • “Referer” (Sic) • Page user came from by following link

  4. Client / Session Identification HTTP Header • HTTP Header fields: • “Authorization” • User name and password • “Client-ip” • “X-Forwarded-For” • Client-ip • “Cookie”

  5. Client / Session Identification • User-Agent • Gives the server information about the browser.

  6. Client / Session Identification:HTTP Header • All contents of the header / URL can be easily forged. • Secure protocols need to use good encryption and a challenge / response scheme to avoid replay attacks.

  7. Client / Session Identification • Client IP Address • Not part of the HTTP header • Available from the package • Easily spoofed • Changed by NATs and Proxies • Not secure for maintaining state

  8. Client / Session Identification:HTTP Authentication • HTTP login based on WWW-Authenticate and Authorization headers. • Browser requests page with GET • Server answers with: 401 Login Required, WWW-authenticate: Basic realm=“joe” • Browser pop’s up login dialog that users fills out. • Browser resends GET request, adds Authorization: Basic am98re45 • Server fulfills request. • Browser now will resend stored user-name with every request.

  9. Client / Session Identification:HTTP Authentication • HTTP Authentication Details • Realms allow the web-site to have many secure areas. • HTTP packs user-name and password together, separated by a colon and encodes them in Base 64 encoding. • HTTP allows authentication by proxies. • User goes to proxy site for authentication. • User-name and password are then used to go to the target sites.

  10. Client / Session Identification:HTTP Authentication • HTTP Authentication Security Risks • Username and password are encoded, not encrypted. • Base 64 encoding and decoding tools are freely available for those that do not want to program them themselves. • Authentication information does not change between different requests. • Sniffer can replay! • Requesting unnecessary authentication leads to password sharing. • Basic authentication only authenticates the browser (user), not the server. • Impersonating websites could harvest passwords.

  11. Client / Session Identification:Digest Authentication • HTTP Digest Authentication • A rarely used alternative that is more secure. • Prevents replay attacks by using nonces. • Encrypts passwords. • Optionally protects message integrity. • …

  12. Client / Session Identification:Fat URL • Fat URL • Maintain state information in the URL • Server generates a session id. • Server adds session id to all URLs requested from the hyperlink. • Amazon.com uses this technique. • http://www.amazon.com/exec/obidos/subst/home/home.html/103-6082309-4209430 • http://www.amazon.com/exec/obidos/ASIN/0439784549/ref=s9_ts_r/103-6082309-4209430 • http://www.amazon.com/gp/cart/view.html/ref=ord_cart_shr/103-6082309-4209430

  13. Client / Session Identification:Fat URL • URLs can be easily faked. • FAT URLs need to be encrypted. • Website needs to do more processing for fat URLs. • Sharing URLs can lead to sharing authentication. • Caching no longer works. • Access is lost when user leaves the website temporarily.

  14. Cookies • Cookies: • ASCI strings stored at the browser. • Submitted with each request to a target website.

  15. Cookies • Cookies: • Session cookies • Stored only for the duration of a web-session. • Persistent cookies • Remain stored until they expire.

  16. Cookies • Cookie-Jar • Client-side state storage • Netscape / Firefox store cookies in a single text file called cookies.txt • MS IE stores cookies in the cache.

  17. Cookies • Server specifies optional domain. • Cookie gets sent with all requests to this domain. • Server specifies optional expiration date • Server can specify “secure” option: • Cookie is only sent when using SSL.

  18. Cookies • Version 0 cookies (Netscape cookies) Set-Cookie: name=value [;expires=date] [;path=path] [;domain-name = value] [;secure] Set-Cookie: customer=Mary; expires Wednesday, 09-September-2006 24:00:01 GMT; domain=“scu.edu”; path=/soe; secure

  19. Cookies • Version 1 cookies (RFC 296) • Less-used • Provides a number of extensions

  20. Cookies • Privacy risk • Can be controlled by web-browser. • Used to track consumer behavior. • Harder, but possible to track an individual user.

  21. Cookies • Security Risk • Users can change cookies before continuing to browse. • Counter-measure: strong encryption • Users could swap / steal cookies. • E.g. when used for authentication • Session Hijacking

  22. Cookies • Session Hijacking • Counter measure: • Server needs to send a new cookie after every change in state and verify that a request comes with a valid cookie. • For example, by appending a MAC of session state to the cookie after each change of state.

  23. Cookies • Poor practices: • Poor encryption of cookies. • Web-based email uses a cookie for authentication. • Cookie contains the user name encrypted by XOR-ing with a secret string. • Attacker can crack the cookie encryption by creating fake accounts. • Attacker can now craft a cookie useful for authentication. • Something similar happened to hotmail and yahoo early on.

  24. Cookies • Poor practices: • Poor encryption of cookies. • Shopping cart encoded in cookie. • Cookie contained shopping cart details in plain text. • Attacker changed prices of items. • Relying on cookie for authentication • Cookie is sniffed from the net. • Cookie is stolen by impersonating a web-site.

  25. Cookie Alternative: Web Bugs • Used to track viewers of web-sites. • HTML page contains a request to download a resource from a “counting” site. • The resource is so small that the viewer does not notice the download. • Counting site receives the request and adds IP address to its user database.

  26. Cookie Alternative: Web Bugs • Examples: • Found by Privacy Foundation on Intuit’s home page for Quicken.com several years ago. <img src=“http://ad.doubleclick.net/ad/pixel./quicken/NEW” width=1 height=1 border=0> <IMG WIDTH=1 HEIGHT=1 border=0 SRC=“http://media.preferences.com/ping?ML_SD=IntuitTE_Intuit_1x1_RunOfSite_Any&db_acfr=4B31-C2FB-10E2&event=reghome&group=register&time=1999.10.27.20.5 6.37”>

  27. Cookie Alternative: Web Bugs • Can be embedded in any html code. • User profiles written in html. • Email messages. • But only when read with a client that can display HTML messages and with a computer connected to the internet. • Usenet messages.

More Related