Lecture 14 Cookies and CSRF

Cookies

Why Cookie?

HTTP is a request-response protocol, the web server processes each request independently of other requests

What if we want our responses to be customized? Example:

• If I enable dark mode on a website, I want future responses from the website to be in dark mode
• If I log in to a website, I want future responses from the website to be related to my account

We need: the response will be customized based on the previous request or the user's preference

Hence, we offer the concept of cookie

1. Cookie: a piece of meta-data used to maintain state across multiple requests
2. This meta-data is stored and remembered by the browser, and sent to server when needed

• 创建 Cookie: 服务器和浏览器都可以创建 Cookie
• 存储 Cookie: 只有浏览器可以存储 Cookie，服务器无法存储

How to use Cookie?

Server 和 JavaScript 都能创建 Cookie，为什么要这样设计？

1. 服务器创建 Cookie：

   • 服务器通过在 HTTP 响应头中使用 Set-Cookie 指令来创建 Cookie。当浏览器接收到带有 Set-Cookie 的响应时，它会将该 Cookie 保存到浏览器的 Cookie 存储中，供后续请求使用。
   • 例如，服务器在用户登录成功后可以发送一个 Set-Cookie，让浏览器记住用户的登录状态。

   示例：

   HTTP/1.1 200 OK
   Set-Cookie: sessionId=abc123; Path=/; HttpOnly
   

   这个响应会告诉浏览器设置一个名为 sessionId 的 Cookie。

2. JavaScript 创建 Cookie：

   • 浏览器中的 JavaScript 代码也可以使用 document.cookie 接口来创建或修改 Cookie。这通常用于客户端的需求，例如在前端应用程序中管理某些轻量级状态。
   • 但是，使用 JavaScript 创建的 Cookie 通常比服务器端的 Cookie 有更多的限制（例如 HttpOnly 属性阻止 JavaScript 访问某些 Cookie）。

   示例：

   document.cookie = "theme=dark; path=/";
   

   这个代码会在浏览器中设置一个名为 theme 的 Cookie。

Summary

• 服务器创建 Cookie 是通过 HTTP 响应头的 Set-Cookie，并将这些信息发送到浏览器；这些 Cookie 通常用于识别用户会话、存储认证信息等。
• JavaScript 创建 Cookie 可以通过前端代码直接操作 document.cookie，用于前端相关的数据保存，如用户界面偏好（比如图片中提到的“dark mode”）。
• 两者的区别在于：
  • 服务器创建的 Cookie 更常用于服务器与客户端之间的会话保持和验证
  • JavaScript 创建的 Cookie 更常用于前端的临时数据保存和控制

Components of Cookie

回忆上文，我们讲到cookie存储在browser端，在cookie jar中，这里我们考察的过程是：存储在browser-side的cookie向server发送

1. The domain attribute and path attribute define which requests the browser should attach this cookie for.
2. The Secure attribute and HttpOnly attribute restrict the cookie for security purposes
   • If the Secure attribute is True, then the browser only sends the cookie if the request is made over HTTPS (and doesn't send the cookie with HTTP requests)
   • If the HttpOnly attribute is True, then the browser doesn't allow JavaScript to access the cookie
3. The Expires attribute defines when the cookie is no longer valid

Cookie Policy

Recall:

1. The server can create a cookie by including a Set-Cookie header in its response.
2. The browser automatically attaches relevant cookies in every request.

Hence:

1. A server should not be able to set cookies for unrelated websites.
2. Cookies should not be sent to the wrong websites.

Setting Cookie

Here we stand on the server-side to analyze

Sending Cookie

Here we stand on the browser-side to analyze

Analysis of Setting and Sending

Session Authentication

Session: A sequence of requests and responses associated with the same authenticated user

Session token: A secret value used to associate requests with an authenticated user

Design

Session tokens can be implemented with cookies. (Cookies can be used to save any state across requests)

Security Issue

If an attacker steals your session token, they can log in as you!

• The attacker can make requests and attach your session token.
• The server will think the attacker’s requests come from you :(

Attribute Setting

• Domain and Path: cookie is only sent on requests that require authentication
• Secure: set to True to so the cookie is only sent over secure HTTPS connections
• HttpOnly: set to True so JavaScript can’t access session tokens
• Expires: set cookie expires when the session times out

Cross-Site Request Forgery (CSRF)

Cross-site request forgery (CSRF or XSRF): An attack that exploits cookie-based authentication to perform an action as the victim

• Victim's browser will automatically attach relevant cookies
• Server will think the request is from the victim

Executing a CSRF Attack

Review step2 above: Attacker tricks the victim into making a malicious request to the server

Review GET leads to open :)

1) How might we trick the victim into making a GET request?

• Strategy #1: Trick the victim into clicking a link
  • The link can directly make a GET request, and open an attacker’s website, which contains some JavaScript that makes the actual malicious request.
• Strategy #2: Put some HTML on a website the victim will visit
  • HTML to automatically make a GET request to a URL:
  • This HTML will probably return an error or a blank 1 pixel by 1 pixel image (too small for user to find), but the GET request will still be sent... with the relevant cookies!

2) How might we trick the victim into making a POST request?

• Strategy #1: Trick the victim into clicking a link
  • Note: Clicking a link in your browser makes a GET request, not a POST request, so the link cannot directly make the malicious POST request.
  • The link can open an attacker’s website, which contains some JavaScript that makes the actual malicious POST request
• Strategy #2: Put some JavaScript on a website the victim will visit
  • JavaScript to automatically make a POST request to a URL
  • Pay for an advertisement on the website, and put JavaScript in the ad :)

CSRF Defense

CSRF Token: A secret value provided by the server to the user.

• The user must attach the same value in the request for the server to accept the request.
• The attacker does not know the token when tricking the user into making a request.

Referer Header: A header in an HTTP request that indicates which webpage made the request

• Allow same-site requests, but disallow cross-site requests
• Header may be blank or removed for privacy reasons

Same-site cookie attribute:

• The cookie is sent only when the domain of the cookie exactly matches the domain of the origin
• Not implemented on all browsers

???+ warning"Same-Site Attribute ≠ Same-Origin Policy"

- Same-Origin Policy: protocol, domain, and port
- Same-Site: domain