2 of 70

Announcements

There will be no discussion on Thursday because of the midterm, but there will still be lecture.
The midterm is this Thursday, July 13th 5–7pm PT in Dwinelle 155.

Details can be found on https://su23.cs161.org/exam/

HW 4 has been released, is in scope, and will be due Friday, July 14 at 11:59 PM PT.
Project 2 spec is up on the website

Rewritten alternative spec (beta) will be out before the midterm, please help us test this for future semesters. It will have some additional/alternative wordings and presentations of the requirements, which may be helpful to you
The first design document draft will be due Monday, July 17th at 11:59 PM PT.
We will tentatively host a Project 2 Mixer this Friday, July 14th for y'all to meet project partners. This project is best done in a pair.

Computer Science 161

3 of 70

Exam Preparation Tips

4 of 70

Before the Exam

Practice practice practice

Do discussion worksheets
Do past exams
For questions you don’t understand, watch walkthrough videos, ask questions on Ed, ask your friends/project partners

Teaching is the best way to learn content :)

Questions will be twists on content seen in lecture, project, HW

For mem safety: What type of vulnerability is this? What is the intuition behind this type of attack.
For crypto: think what is this scheme similar to? What are the key differences between a known scheme and an exam scheme
Don’t just copy paste exploits this won’t work! Understand the intuition behind exploits

If you’re worried about forgetting anything, put it on your cheat sheet!

5 of 70

Memory Safety Tips

Identify the line of vulnerable code

Should look like previously seen vulnerable lines of code
Will help you determine what type of attack to perform

Draw Stack Diagrams

Even if we don’t ask you pls :D
Write down how many bytes each variable takes up
If you are given addresses, mark them down
If there are pointers, note where they point to

There is a difference between needing a pointer vs needing the direct value

Understand calling convention

Think of where your ebp, esp, eip will point at the end of the vulnerable function

If defenses are enabled

Think of common ways to subvert them and use those strategies

6 of 70

Crypto Tips

Both types of crypto

Determinism == not IND-CPA secure
Usually easier to prove something is IND-CPA not secure than proving it is secure

Symmetric Crypto

Think what mode of operation is this similar to? What are the properties of that mode?
Remember D_k(C_i) doesn’t necessarily equal M_i directly and vice versa for encryption
Be methodical in your XOR math
Look at equations to determine if things are parallelizable

If you need C_i-1 or M_i-1 then it’s not parallelizable!

Asymmetric Crypto

Based on mathematical equations - usually questions involve manipulation of equations
Remember math tricks (mainly exponent addition/multiplication)
More susceptible to man in the middle attacks

7 of 70

HTTP is largely stateless
Cookies are a way to add state. This state helps link the same user’s requests and helps customize websites for the user

8 of 70

A way of maintaining state in the browser

Browser

GET …

Server

Browser maintains cookie jar with all cookies it receives

http response contains

9 of 70

Setting/deleting cookies by server

The first time a browser connects to a particular web server, it has no cookies for that web server
When the web server responds, it includes a Set-Cookie: header that defines a cookie
Each cookie is just a name-value pair (with some extra metadata)

GET …

HTTP Header:

Set-cookie: NAME=VALUE ;

Server

10 of 70

View a cookie

In a web console (chrome, view->developer->developer tools), type

document.cookie

to see the cookie for that site

Each name=value is one cookie.

document.cookie lists all cookies in scope for document

11 of 70

Cookie scope

When the browser connects to the same server later, it automatically attaches the cookies in scope: header containing the name and value, which the server can use to connect related requests.
Domain and path inform the browser about which sites to send this cookie to

GET …

HTTP Header:

Set-cookie🍪:NAME=VALUE ;

domain = (when to send) ;

path = (when to send)

Server

12 of 70

Cookie scope

HTTP Header:

Set-cookie🍪:NAME=VALUE ;

domain = (when to send) ;

path = (when to send)

secure = (only send over HTTPS);

GET …

Server

Secure: sent over https only

https provides secure communication using TLS (encryption and authentication)

13 of 70

Cookie scope

GET …

HTTP Header:

Set-cookie🍪:NAME=VALUE ;

domain = (when to send) ;

path = (when to send)

secure = (only send over SSL);

expires = (when expires) ;

HttpOnly

Server

Expires is expiration date

Delete cookie by setting “expires” to date in past

HttpOnly: cookie cannot be accessed by Javascript, but only sent by browser (defense in depth, but does not prevent XSS)

14 of 70

Cookie policy

The cookie policy has two parts:

What scopes a URL-host name web server is allowed to set on a cookie
When the browser sends a cookie to a URL

15 of 70

Cookie scope

Scope of cookie might not be the same as the URL-host name of the web server setting it

16 of 70

What scope a server may set for a cookie

domain: any domain-suffix of URL-hostname, except TLD

example: host = “login.site.com”

⇒ login.site.com can set cookies for all of .site.com � but not for another site or TLD

Problematic for sites like .berkeley.edu

path: can be set to anything

allowed domains

.site.com

disallowed domains

user.site.com

othersite.com

.com

top-level domains

e.g. ‘.com’

The browser checks if the web server may set the cookie, and if not, it will not accept the cookie.

17 of 70

Examples

Credits: The Tangled Web: A Guide to Securing Modern Web Applications, by Michał Zalewski

Whether it will be set

domain

Web server at foo.example.com wants to set cookie with domain:

yes

18 of 70

When browser sends cookie

Browser sends all cookies in URL scope:

cookie-domain is domain-suffix of URL-domain, and
cookie-path is prefix of URL-path, and
[protocol=HTTPS if cookie is “secure”]

GET //URL-domain/URL-path

Cookie: NAME = VALUE

Server

Goal: server only sees cookies in its scope

19 of 70

When browser sends cookie

A cookie with

domain = example.com, and

path = /some/path/

will be included on a request to

http://foo.example.com/some/path/subdirectory/hello.txt

GET //URL-domain/URL-path

Cookie: NAME = VALUE

Server

20 of 70

Examples: Which cookie will be sent?

cookie 1

name = userid

value = u1

domain = login.site.com

path = /

non-secure

cookie 2

name = userid

value = u2

domain = .site.com

path = /

non-secure

http://checkout.site.com/

http://login.site.com/

http://othersite.com/

cookie: userid=u2

cookie: userid=u1, userid=u2

cookie: none

21 of 70

Examples

Credits: The Tangled Web: A Guide to Securing Modern Web Applications, by Michał Zalewski

Whether it will be set, and if so, where it will be sent to

domain

Web server at foo.example.com wants to set cookie with domain:

22 of 70

Examples

Credits: The Tangled Web: A Guide to Securing Modern Web Applications, by Michał Zalewski

Whether it will be set, and if so, where it will be sent to

domain

Web server at foo.example.com wants to set cookie with domain:

23 of 70

Examples

http://checkout.site.com/

http://login.site.com/

https://login.site.com/

cookie 1

name = userid

value = u1

domain = login.site.com

path = /

secure

cookie 2

name = userid

value = u2

domain = .site.com

path = /

non-secure

cookie: userid=u2

cookie: userid=u1; userid=u2

(arbitrary order)

24 of 70

Client side read/write: document.cookie

Setting a cookie in Javascript:

document.cookie = “name=value; expires=…; ”

Reading a cookie: alert(document.cookie)

prints string containing all cookies available for document (based on [protocol], domain, path)

Deleting a cookie:

document.cookie = “name=; expires= Thu, 01-Jan-00”

document.cookie often used to customize page in Javascript

25 of 70

Viewing/deleting cookies in Browser UI

Firefox: Tools -> page info -> security -> view cookies

26 of 70

Cookie policy versus �same-origin policy

27 of 70

Cookie policy: when browser sends cookie

A cookie with

domain = example.com, and

path = /some/path/

will be included on a request to

http://foo.example.com/some/path/subdirectory/hello.txt

GET //URL-domain/URL-path

Cookie: NAME = VALUE

Server

28 of 70

Cookie policy versus same-origin policy

Consider Javascript on a page loaded from a URL U
If a cookie is in scope for a URL U, it can be accessed by Javascript loaded on the page with URL U,

unless the cookie has the httpOnly flag set.

So there isn’t exact domain match as in same-origin policy, but the cookie policy is invoked instead.

29 of 70

Examples

cookie 1

name = userid

value = u1

domain = login.site.com

path = /

non-secure

cookie 2

name = userid

value = u2

domain = .site.com

path = /

non-secure

http://checkout.site.com/

http://login.site.com/

http://othersite.com/

cookie: userid=u2

cookie: userid=u1, userid=u2

cookie: none

JS on each of these URLs can access the corresponding cookies even if the domains are not the same

30 of 70

Indirectly bypassing same-origin policy using cookie policy

Since the cookie policy and the same-origin policy are different, there are corner cases when one can use cookie policy to bypass same-origin policy
Ideas how?

31 of 70

Example

financial.example.com

web server

blog.example.com

web server

(assume attacker compromised this web server)

Victim user browser

financial.example.com

cookies in jar with domain example.com

The browser will send the cookie for financial.example.com to blog.example.com due to domain

blog.example.com

Cookies from:

32 of 70

Example

financial.example.com

web server

blog.example.com

web server

(assume attacker compromised this web server)

Victim user browser

financial.example.com

cookie jar

Browsers maintain a separate cookie jar per domain group, such as one jar for *.example.com to avoid one domain filling up the jar and affecting another domain. Each browser decides at what granularity to hold group domains.

blog.example.com

Cookies from:

(domain:financial.example.com)

33 of 70

Example

financial.example.com

web server

blog.example.com

web server

(assume attacker compromised this web server)

Victim user browser

financial.example.com

cookie jar for *.example.com

blog.example.com

example.com

GET

set-cookie:

Attacker sets many cookies with domain example.com which overflows the cookie jar for domain *.example.com and overwrites cookies from financial.example.com

34 of 70

Example

financial.example.com

web server

blog.example.com

web server

(assume attacker compromised this web server)

Victim user browser

example.com

cookie jar for *.example.com

example.com

Attacker sets many cookies with domain example.com which overflows the cookie jar for domain *.example.com and overwrites cookies from financial.example.com

35 of 70

Example

financial.example.com

web server

Victim user browser

example.com

cookie jar for *.example.com

example.com

GET

When Alice visits financial.example.com, the browser automatically attaches the attacker’s cookies due to cookie policy (the scope of the cookies is a domain suffix of financial.example.com)

Why is this a problem?

36 of 70

Indirectly bypassing same-origin policy using cookie policy

Victim thus can login into attackers account at financial.example.com
This is a problem because the victim might think its their account and might provide sensitive information
This also bypassed same-origin policy (indirectly) because blog.example.com influenced financial.example.com

37 of 70

RFC6265

For further details on cookies, checkout the standard RFC6265 “HTTP State Management Mechanism”

https://tools.ietf.org/html/rfc6265

- Browsers are expected to implement this reference, and any differences are browser specific

38 of 70

Session Tokens

Computer Science 161

Fall 2022

39 of 70

Session Authentication

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

Example: When you check all your unread emails, you make many requests to Gmail. The Gmail server needs a way to know all these requests are from you
When the session is over (you log out, or the session expires), future requests are not associated with you

Naïve solution: Type your username and password before each request

Problem: Very inconvenient for the user!

Better solution: Is there a way the browser can automatically send some information in a request for us?

Yes: Cookies!

Computer Science 161

Fall 2022

40 of 70

Session Authentication: Intuition

Imagine you’re attending a concert
The first time you enter the venue:

Present your ticket and ID
The doorperson checks your ticket and ID
If they’re valid, you receive a wristband

If you leave and want to re-enter later

Just show your wristband!
No need to present your ticket and ID again

Computer Science 161

Fall 2022

41 of 70

Session Tokens

Session token: A secret value used to associate requests with an authenticated user
The first time you visit the website:

Present your username and password
If they’re valid, you receive a session token
The server associates you with the session token

When you make future requests to the website:

Attach the session token in your request
The server checks the session token to figure out that the request is from you
No need to re-enter your username and password!

Computer Science 161

Fall 2022

42 of 70

Session Tokens with Cookies

Session tokens can be implemented with cookies

Cookies can be used to save any state across requests (e.g. dark mode)
Session tokens are just one way to use cookies

The first time you visit a website:

Make a request with your username and password
If they’re valid, the server sends you a cookie with the session token
The server associates you with the session token

When you make future requests to the website:

The browser attaches the session token cookie in your request
The server checks the session token to figure out that the request is from you
No need to re-enter your username and password!

When you log out (or when the session times out):

The browser and server delete the session token

Computer Science 161

Fall 2022

43 of 70

Session Tokens: Security

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

The attacker can make requests and attach your session token
The browser will think the attacker’s requests come from you

Servers need to generate session tokens randomly and securely
Browsers need to make sure malicious websites cannot steal session tokens

Enforce isolation with cookie policy and same-origin policy

Browsers should not send session tokens to the wrong websites

Enforced by cookie policy

Computer Science 161

Fall 2022

44 of 70

Session Token Cookie Attributes

What attributes should the server set for the session token?

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

Name	token
Value	{random value}
Domain	mail.google.com
Path	/
Secure	True
HttpOnly	True
Expires	{15 minutes later}
(other fields omitted)

Computer Science 161

Fall 2022

45 of 70

Cross-Site Request Forgery (CSRF)

Computer Science 161

Fall 2022

46 of 70

Review: Cookies and Session Tokens

Session token cookies are used to associate a request with a user
The browser automatically attaches relevant cookies in every request

Computer Science 161

Fall 2022

47 of 70

Cross-Site Request Forgery (CSRF)

Idea: What if the attacker tricks the victim into making an unintended request?

The victim’s browser will automatically attach relevant cookies
The server will think the request came from the victim!

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

Computer Science 161

Fall 2022

48 of 70

Steps of a CSRF Attack

Attacker

User

Server

Computer Science 161

Fall 2022

49 of 70

Steps of a CSRF Attack

User authenticates to the server

User receives a cookie with a valid session token

Attacker

User

Server

1. Login

Computer Science 161

Fall 2022

50 of 70

Steps of a CSRF Attack

User authenticates to the server

User receives a cookie with a valid session token

Attacker tricks the victim into making a malicious request to the server

Attacker

User

Server

1. Login

2. Make this request

Computer Science 161

Fall 2022

51 of 70

Steps of a CSRF Attack

User authenticates to the server

User receives a cookie with a valid session token

Attacker tricks the victim into making a malicious request to the server
The server accepts the malicious request from the victim

Recall: The cookie is automatically attached in the request

Attacker

User

Server

1. Login

2. Make this request

3. Malicious request

Computer Science 161

Fall 2022

52 of 70

Steps of a CSRF Attack

User authenticates to the server

User receives a cookie with a valid session token

Attacker tricks the victim into making a malicious request to the server
The server accepts the malicious request from the victim

Recall: The cookie is automatically attached in the request

Computer Science 161

Fall 2022

53 of 70

Executing a CSRF Attack

How might we trick the victim into making a GET request?
Strategy #1: Trick the victim into clicking a link

Later we’ll see how to trick a victim into clicking a link
The link can directly make a GET request:�https://www.bank.com/transfer?amount=100&to=Mallory
The link can 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

Example: The victim will visit a forum. Make a post with some HTML on the forum
HTML to automatically make a GET request to a URL:�<img src="https://www.bank.com/transfer?amount=100&to=Mallory">

This HTML will probably return an error or a blank 1 pixel by 1 pixel image, but the GET request will still be sent...with the relevant cookies!

Computer Science 161

Fall 2022

54 of 70

Executing a CSRF Attack

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

Example POST request: Submitting a form

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

Example: Pay for an advertisement on the website, and put JavaScript in the ad
Recall: JavaScript can make a POST request

Computer Science 161

Fall 2022

55 of 70

Top 25 Most Dangerous Software Weaknesses (2023)

Computer Science 161

Fall 2022

56 of 70

CSRF Example: YouTube

2008: Attackers exploit a CSRF vulnerability on YouTube
By forcing the victim to make a request, the attacker could:

Add any videos to the victim’s "Favorites"
Add any user to the victim’s "Friend" or "Family" list
Send arbitrary messages as the victim
Make the victim flag any videos as inappropriate
Make the victim share a video with their contacts
Make the victim subscribe to any channel
Add any videos to the user’s watchlist

Takeaway: With a CSRF attack, the attacker can force the victim to perform a wide variety of actions!

Computer Science 161

Fall 2022

57 of 70

CSRF Example: Facebook

Takeaway: The HTML image tag can be used to execute a CSRF attack

	Link
Facebook Hit by Cross-Site Request Forgery Attack
Sean Michael Kerner	August 21, 2009
Nevertheless, that Facebook accounts were compromised in the wild is noteworthy because the attack used a legitimate HTML tag to violate users’ privacy. According to Zilberman’s disclosure, the attack simply involved the malicious HTML image tag residing on any site, including any blog or forum that permits the use of image tags even in the comments section. "The attack elegantly ends with a valid image so the page renders normally, and the attacked user does not notice that anything peculiar has happened," Zilberman said.

Computer Science 161

Fall 2022

58 of 70

CSRF Defenses

Computer Science 161

Fall 2022

59 of 70

CSRF Defenses

CSRF defenses are implemented by the server (not the browser)
Defense: CSRF tokens
Defense: Referer validation
Defense: SameSite cookie attribute

Computer Science 161

Fall 2022

60 of 70

CSRF Tokens

Idea: Add a secret value in the request that the attacker doesn’t know

The server only accepts requests if it has a valid secret
Now, the attacker can’t create a malicious request without knowing the secret

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.

CSRF tokens cannot be sent to the server in a cookie!

The token must be sent somewhere else (e.g. a header, GET parameter, or POST content)

CSRF tokens are usually valid for only one or two requests

Computer Science 161

Fall 2022

61 of 70

CSRF Tokens: Usage

Example: HTML forms

Forms are vulnerable to CSRF

If the victim visits the attacker’s page, the attacker’s JavaScript can make a POST request with a filled-out form

CSRF tokens are a defense against this attack

Every time the user requests a form from the legitimate website, the server attaches a CSRF token as a hidden form field (in the HTML, but not visible to the user)
When the user submits the form, the form contains the CSRF token
The attacker’s JavaScript won’t be able to create a valid form, because they don’t know the CSRF token!
The attacker can try to fetch their own CSRF token, but it will only be valid for the attacker, not the victim

Computer Science 161

Fall 2022

62 of 70

CSRF Tokens: Usage

Server

1. Login

Attacker

3. Make this request

2. Get token

User

4. Make request

The request in step 4 will fail, because the attacker doesn’t know the token!

Computer Science 161

Fall 2022

63 of 70

Referer Header

Idea: In a CSRF attack, the victim usually makes the malicious request from a different website
Referer header: A header in an HTTP request that indicates which webpage made the request

“Referer” is a 30-year typo in the HTTP standard (supposed to be “Referrer”)!
Example: If you type your username and password into the Facebook homepage, the Referer header for that request is https://www.facebook.com
Example: If an img HTML tag on a forum forces your browser to make a request, the Referer header for that request is the forum’s URL
Example: If JavaScript on an attacker’s website forces your browser to make a request, the Referer header for that request is the attacker’s URL

Computer Science 161

Fall 2022

64 of 70

Referer Header

Checking the Referer header

Allow same-site requests: The Referer header matches an expected URL

Example: For a login request, expect it to come from https://bank.com/login

Disallow cross-site requests: The Referer header does not match an expected URL

If the server sees a cross-site request, reject it

Computer Science 161

Fall 2022

65 of 70

Referer Header: Issues

The Referer header may leak private information

Example: If you made the request on a top-secret website, the Referer header might show you visited http://intranet.corp.apple.com/projects/iphone/competitors.html
Example: If you make a request to an advertiser, the Referer header gives the advertiser information about how you saw the ad

The Referer header might be removed before the request reaches the server

Example: Your company firewall removes the header before sending the request
Example: The browser removes the header because of your privacy settings

The Referer header is optional. What if the request leaves the header blank?

Allow requests without a header?

Less secure: CSRF attacks might be possible

Deny requests without a header?

Less usable: Legitimate requests might be denied

Need to consider fail-safe defaults: No clear answer

Computer Science 161

Fall 2022

66 of 70

SameSite Cookie Attribute

Idea: Implement a flag on a cookie that makes it unexploitable by CSRF attacks

This flag must specify that cross-site requests will not contain the cookie

SameSite flag: A flag on a cookie that specifies it should be sent only when the domain of the cookie exactly matches the domain of the origin

SameSite=None: No effect
SameSite=Strict: The cookie will not be sent if the cookie domain does not match the origin domain
Example: If https://evil.com/ causes your browser to make a request to https://bank.com/transfer?to=mallory, cookies for bank.com will not be sent if SameSite=Strict, because the origin domain (evil.com) and cookie domain (bank.com) are different

Issue: Not yet implemented on all browsers

Computer Science 161

Fall 2022

67 of 70

Cookies: Summary

Cookie: a piece of data used to maintain state across multiple requests

Set by the browser or server
Stored by the browser
Attributes: Name, value, domain, path, secure, HttpOnly, expires

Cookie policy

Server with domain X can set a cookie with domain attribute Y if the domain attribute is a domain suffix of the server’s domain, and the domain attribute Y is not a top-level domain (TLD)
The browser attaches a cookie on a request if the domain attribute is a domain suffix of the server’s domain, and the path attribute is a prefix of the server’s path

Computer Science 161

Fall 2022

68 of 70

Session Authentication: Summary

Session authentication

Use cookies to associate requests with an authenticated user
First request: Enter username and password, receive session token (as a cookie)
Future requests: Browser automatically attaches the session token cookie

Session tokens

If an attacker steals your session token, they can log in as you
Should be randomly and securely generated by the server
The browser should not send tokens to the wrong place

Computer Science 161

Fall 2022

69 of 70

CSRF: Summary

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

User authenticates to the server

User receives a cookie with a valid session token

Attacker tricks the victim into making a malicious request to the server
The server accepts the malicious request from the victim

Recall: The cookie is automatically attached in the request

Attacker must trick the victim into creating a request

GET request: click on a link
POST request: use JavaScript

Computer Science 161

Fall 2022

70 of 70

CSRF Defenses: Summary

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

Computer Science 161

Fall 2022