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” User’s 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

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

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

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.

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

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

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.

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.

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

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.

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.

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

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

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.

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.

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 :00:01 GMT; domain=“scu.edu”; path=/soe; secure

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

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

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

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.

Cookies Poor practices: Poor encryption of cookies. Web-based 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.

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.

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.

Cookie Alternative: Web Bugs Examples: Found by Privacy Foundation on Intuit’s home page for Quicken.com several years ago. <IMG WIDTH=1 HEIGHT=1 border=0 SRC=“ nOfSite_Any&db_acfr=4B31-C2FB- 10E2&event=reghome&group=register&time= ”>

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