Lecture 13: Cookies, Session Management, and CSRF

• Slides
• Playlist (length: 1:37:02)

Intro to Cookies

Why do we need cookies to maintain state across multiple HTTP requests?

HTTP is a stateless protocol, which means each request has no knowledge of any other requests.

Viewing Cookies

What stateful information might the cookies on cnn.com be storing in cookies?

Some possible answers: time zone, personal settings (such as dark mode), tracking data for advertising.

For example, if you change the website to dark mode and load an article, the cookie that gets sent to the server will tell the server to load the article in dark mode.

Cookie Scopes

Why do we need to define domain and path scopes for each cookie, instead of sending every cookie in the browser on every request?

Some cookies may have sensitive data that shouldn’t be sent to all websites.

Setting Cookie Scope

Why might we want to let mail.google.com set a cookie for google.com?

There may be many shared services under one domain, like maps.google.com, mail.google.com, etc. The policy for setting cookies allows any one of these services to set a cookie for all Google services.

This could have security vulnerabilities if different subdomains are run by different organizations, such as eecs.berkeley.edu and math.berkeley.edu.

Scope for Sending Cookies

If Cookie 1’s path was changed to /user, which of the three domains would it be sent to?

None. All three domains have path /, and /user is not a prefix of /.

Examples of Setting and Sending Cookies

Modifying Cookies in Browser

See Q3.5-Q3.9 on Homework 6 for some practice on viewing and modifying cookies in your browser.

Cookie Policy vs. Same-Origin Policy

Bypassing Same-Origin Policy with Cookies

What difference between the same-origin policy and cookie policy causes this vulnerability?

(Fill in the blanks: Same-origin policy thinks that financial.example.com and blog.example.com are controlled by ___ (the same/different) organization(s) because ___, but cookie policy thinks they are controlled by ___ (the same/different) organization(s) because ___.)

Same-origin policy thinks that financial.example.com and blog.example.com are controlled by different organizations because their domains are different, but cookie policy thinks they are controlled by the same organization because both can set a cookie for example.com.

Session Management with HTTP Auth

Session Token Analogy

Session Tokens

Storing Session Tokens

When could a man-in-the-middle attacker on the network steal a user’s session token?

All three options for storing a session token are at the application layer, so the MITM attacker just needs to be able to see the application layer payload to steal the session token.

If the request is sent over HTTP, the MITM attacker can always steal the session token. If the request is sent over HTTPS, the MITM attacker can’t steal the session token.

Cross-Site Request Forgery (CSRF)

HTML Forms

Why do we prefer sending HTML forms using HTTP POST requests instead of GET requests?

Submitting forms usually causes the server to change some internal state, like changing your bank account balance. By convention, we use POST requests when a request causes the server state to change.

Session Management with Cookies

Cross-Site Request Forgery (CSRF)

Fill in the blanks with (attacker/victim/server) or (GET/POST): In a CSRF attack, the ___ sends an HTTP ___ request to the ___. The ___ responds with some HTML that fills out a form with malicious input and some Javascript that sends the form to the ___. The ___ sends the filled-out form to the ___ as an HTTP ___ request, along with any browser cookies. The ___ thinks this request is legitimate and accepts the malicious form input.

In a CSRF attack, the victim sends an HTTP GET request to the attacker. The attacker responds with some HTML that fills out a form with malicious input and some Javascript that sends the form to the server. The victim sends the filled-out form to the server as an HTTP POST request, along with any browser cookies. The server thinks this request is legitimate and accepts the malicious form input.

Real-World CSRF Attacks

Defense: CSRF Tokens

Would the CSRF token defense work if the server used the same CSRF token for every request, regardless of user?

No. Now the attacker could make a request to the server, see the value of the CSRF token, and use the same value in a CSRF attack. The CSRF token needs to be different for every user.

Defense: Referer Validation

Would referer validation stop the CSRF attack shown at the beginning of the video? Assume the browser attaches the correct referer, and the referer field is not blank.

Yes. The referer field would show attacker.com because the victim was on the attacker’s website when they made the HTTP POST request with the malicious form.

CSRF Conclusion