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 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
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-2006 24: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 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.

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:
<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”>

 Found by Privacy Foundation on Intuit’s home

page for Quicken.com several years ago.
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.