notes.md

1. Cookies and Their Use

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.

Ambient Authority

• 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

Quick primer: Signature Schemes

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 to x on the certificate
• If the value and x are equal, then the verification succeded and the server certificate can be trusted

History of Cookies

• 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

Cookie attributes

• 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
• 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 for stanford.edu

Set-Cookie: theme=dark; Expires=<date>;

How long can cookies last?

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.

How do you delete cookies?

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;

---

2. Session Hijacking Methods

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

Packet sniffing

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

Cross-Site Scripting (XSS)

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 on malwares

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!

---

3. Session hijacking mitigation

• Use HTTPS
• Set the cookie attributes to Secure, HttpOnly and set a Strict or Lax 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.

Ways to combat CSRF

• 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 values Strict or Lax.
  • 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 against POST based CSRF.
• The SameSite attribute is now by default to Lax in modern web browsers, which means that you need to intentionally set it to None to allow cross-origin requests.

Cookie Path bypass

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
• 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

- 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 values `Strict` or `Lax`. 
       - `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 against `POST` based CSRF.

Other ways to hijack session not mentioned above

  - Using malware
  - 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.

How to combat session hijacking:

- use https
- setting cookie attributes
- generating random session id
- regenerating session keys after initial authentication
- perform additional verification beyond the session key (maybe using usual ip address). Also use user inactivity timeout to close the user session after a set idle time.

Some More Recommended Additions:

Ambient Authority:

• In practice explicit authorization would involve having to sign in for every single action
• Ex. On facebook, if you want to give a like, have to sign in using a form along with liking

Quick primer: Signature Schemes:

• Ex. When a servers 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 compare the value to x on the certificate
• If equal, then verification succeded and certificate of server can be trusted

Ways to combat CSRF

• SameSite is set to lax by default nowadays
• Means if we want to allow all cross origin requests, need to set SameSite to None intentionally

3. Session hijacking mitigation:

• Note that even with all these additions, if there is persistent malware on your system
  that is constantly monitoring you, 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
• Hackers can obviously can still get creative

Ways to combat CSRF

• SameSite is set to lax by default nowadays
• Means if we want to allow all cross origin requests, need to set SameSite to None intentionally

I don't think that's true. It was indeed mentioned in the "Incrementally Better Cookies" reading as a future feature that would make cookies more secure, but it's not yet implemented anywhere (that I know of).

I am fine with the notes for the third part Juliette. Can you just move malware part outside, as it is not related to defending against session attacks but to the actual hijacking attack?

Some notes I have to follow the section titled Quick Primer: Signature Schemes.

Getting rid of Signing in favor of Session IDs

• The main problem with using signed cookies, at least for authentication, is that the value of this signed cookie is always the same- Feross demonstrated this problem by changing Bob's password at the bank. Even though Bob's password had changed, the cookie and the tag had not, so if someone were to get that cookie through a session attack, they could authenticate with the server as Bob indefinitely which is obviously not good.
• The solution to this is to throw out this kind of signing and implement a session ID instead. The session ID is basically just a random big number generated by the server and passed to the authenticated client as a cookie. Then, anytime someone shows up and presents that session ID to the server, the server can know which user it is for and how it should apply access control.
• The main distinction between a session ID and a signed cookie is that, when a user logs out, the server can destroy the session ID. That way, say Bob logs out and someone tries to present his last session ID to the server and gain access, they will be unable. When the user logs in next, a new session ID is generated and will be used going forward.