The server can set cookies with the Set-Cookie header (Set-Cookie: theme=dark;
) and the browser automatically sends this cookie back at every request (Cookie: theme=dark;
)
The server does that to implement the idea of a session. The goal is to keep a set of data related to a user's current 'browsing session'.
Examples: logins, shopping carts and user tracking.
- Access control: regulate who can view resources or take actions
- Ambient authority: access control based on a global and persistent property of the requester
- The alternative is explicit authorization valid only for a specific action
- There are four types of ambient authority on the web:
- Cookies: most common and versatile method
- IP checking: used at Stanford for library resources
- Built-in HTTP auth: rarely used
- Client certificates: rarely used
Triple of algorithms (Generator, Signer, Verifier):
- if you call G, the generator returns a public key and a secret key
- you use S to sign: you pass in the secret key and the value you want to sign (x), in order to get a tag (t).
- the verifier V uses the public key, the value x and the tag to check the validity of tag t for given input x
Example:
- When a server needs to prove to a client that it owns the domain it says it does
- Server will have a certificate that contains the value of
x
,t
, and the public key - Client side can decrypt
t
using the public key and can compare the decrypted value tox
on the certificate - If the value and
x
are equal, then the verification succeded and the server certificate can be trusted
- Implemented in 1994 in Netscape and described in 4-page draft
- No spec for 17 years:
- Attempt was made in 1997, but made incompatible changes
- Another attempt in 2000 ("Cookie 2"), with the same problem
- Around 2011, another effort succeeded (RFC 6265)
- Ad-hoc design has led to interesting issues
- Expires: Specifies expiration date. If no date, then lasts for session. (which the browser will remember)
- Path: Scope the "Cookie" header to a particular request path prefix.
- eg.
Path=/docs
will match/docs
and/docs/Web/
- do not use for security
- eg.
- Domain: allows the cookie to be scoped to a domain broader than the domain that returned the
Set-Cookie
header.- eg.
login.stanford.edu
could set a cookie forstanford.edu
- eg.
Set-Cookie: theme=dark; Expires=<date>;
Sites can set Expires
to a very far-future date and the cookie will last until the user clears it. In 2007, Google shortened the expiration date of its cookies from the year 2038 to a two-year life cycle.
When Expires
is not specified, the cookie lasts for the current browser session. However, browsers practice session restoring, so this cookie can last way longer.
Set cookie with the same name and an expiration date in the past. The cookie value can be omitted.
Set-Cookie: key=; Expires=Thu, 01 Jan 1970 00:00:00 GMT;
- Packet sniffing
- XSS
- Using malware (eg. a Trojan horse monitoring your browser activity)
- Brute force
- Session fixation - creating a valid session id and tricking the user into using it. The attacker must first figure out what format of session IDs is valid and then use social engineering such as phishing or a similar attack technique to trick the user into clicking the login link and providing their credential, thus associating the session ID with the account.
Sending cookies over unencrypted HTTP is a very bad idea:
- if anyone sees the cookie (packet sniffing), they can use it to hijack the user's session
- the attacker sends the victim's cookies as if it was their own
- the server will be fooled
Firesheep: looks at the traffic that happens on the local network. Possible to hijack every session at a Starbuck wifi hotspot. (Activism to extend HTTPS to the whole website, not only the login form.)
CSRF - Cross site request forgery is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated.
History:
- In 2006 Netflix website had numerous vulnerabilities to CSRF which allowed an attacker to perform actions such as adding a DVD to the victim's rental queue
- In 2008 Youtube was vulnerable to CSRF and this allowed any attacker to perform nearly all actions of any user
Note that even with all these additions, if there is persistent malware on your system that is constantly monitoring you, you're still vulnerable (hard problem). However the time the attacker has to attack will still be significantly limited (to the time you are logged into the site), not to mention the methods they can use are also limited. But of course, hackers can still get creative!
- Use HTTPS
- Set the cookie attributes to
Secure
,HttpOnly
and set aStrict
orLax
SameSite
(protection against XSS) - Generate a random session id
- Generate new session id after initial authentication
- Generate new session id before accessing sensitive features (eg. payment)
- Perform additional verification beyond the session id (maybe using usual IP address). Also use user inactivity timeout to close the user session after a set idle time.
- Anti CSRF Tokens - these are hidden cookies. One token is sent as a hidden field in the form and other is sent in the header of the response. To authenticate user both tokens need to be provided
SameSite
attribute can be set on cookie with valuesStrict
orLax
.Strict
means CSRF is dead, it won't send the cookie on any cross-origin request at all.- In
Lax
mode there is a single exception to allow cookies to be attached to top-level navigations that use a safe HTTP method. (GET). Still protected againstPOST
based CSRF.
- The
SameSite
attribute is now by default toLax
in modern web browsers, which means that you need to intentionally set it toNone
to allow cross-origin requests.
It's supposed to restrict the use of a cookie for a specific path. However:
- do not use
Path
for security Path
does not protect against unauthorized reading of the cookie from a different path on the same origin:- Can be bypassed using an
<iframe>
with the path of the cookie - Then, read
iframe.contentDocument.cookie
- Can be bypassed using an
- This is allowed by Same Origin Policy
- Only use
Path
as a performance optimization
CSRF Attacts
CSRF - Cross site request forgery is an attack that forces an end user to execute unwanted actions on a web application in which they are currently authenticated.
History:
- In 2006 Netflix website had numerous vulnerabilities to CSRF which allowed an attacker to perform actions such as adding a DVD to the victim's rental queue
- In 2008 Youtube was vulnerable to CSRF and this allowed any attacker to perform nearly all actions of any user
Ways to combat CSRF
Other ways to hijack session not mentioned above
How to combat session hijacking: