Web Security: Session management and CSRFcs161/su19/lectures/lec21_web_4.pdfweb server...

Web Security: Session management and CSRF

CS 161: Computer Security

Ruta Jawale and Rafael Dutra

July 31, 2019

Slides credit: Raluca Ada Popa, David Wagner, Dan Boneh

Announcements

• Project 3 will be released later today

• Office Hours are moving location! (~8/1)

• Homework 2 due this Friday (8/2)

• Midterm 2 is next Monday (8/5)

– Attend lectures and discussions

Attack Server

Victim client

visit web site

receive malicious page

click on linkecho user input

1

2

34

(“Reflected” XSS attack)

Server Patsy/Victim

execute script embedded in input as though server meant us to run it

5

send valuable data

7

perform attacker action

6

Reflected XSS (Cross-Site Scripting)

evil.com

bank.com

XSS Prevention

Preventing XSS

• Input validation: check that inputs are of expected form (whitelisting)■ Avoid blacklisting; it doesn’t work well

• Output escaping: escape dynamic data before inserting it into HTML

Web server must perform:

Output escaping• HTML parser looks for special characters: < > & ” ’

– <html>, <div>, <script>– such sequences trigger actions, e.g., running

script• Ideally, user-provided input string should not contain

special chars• If one wants to display these special characters in a

webpage without the parser triggering action, one has to escape the parser

Character Escape sequence

< <

> >

& &amp

“ "

‘ '

Demo + fix

Direct vs escaped embedding

Attacker input:<script>…</script>

<html>Comment:

</html>

<html>Comment:

</html>

direct

escaped

<script>…</script>

<script>…</script>

browser rendering

browser rendering

Attack! Script runs!

Comment: <script>…</script>

Script does not run but gets displayed!

Escape user input!

XSS prevention (cont’d): Content-security policy (CSP)• Have web server supply a whitelist of the

scripts that are allowed to appear on a page■ Web developer specifies the domains the browser

should allow for executable scripts, disallowing all other scripts (including inline scripts)

• Can opt to globally dis-allow script execution

HTTP Cookie

• Apps do not typically store persistent state in client browsers– User should be able to login from any browser

• Web application servers are generally "stateless": – Most web server applications maintain no information

in memory from request to request • Information typically stored in databases

– Each HTTP request is independent; server can't tell if 2 requests came from the same browser or user.

• Statelessness not always convenient for application developers: need to tie together a series of requests from the same user

HTTP is mostly stateless

• A way of maintaining stateBrowser GET …

Server

Browser maintains cookie jar

HTTP response contains

Cookie

HTTP Header: Set-cookie: NAME=VALUE ;

domain = (when to send) ;path = (when to send);

scope

• When the browser connects to the same server later, it includes a Cookie: 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 … Server

Browser

Cookie Scope


domain = (when to send) ;path = (when to send);secure = (only send over HTTPS);

GET … Server

Browser

Secure Cookie

• Secure flag: cookie sent over https only– https provides secure communication (privacy and

integrity)

scope

GET …


domain = (when to send) ;path = (when to send);secure = (only send over SSL);expires = (when expires) ;HttpOnly = (no JS access);

Server

Browser

scope

• Expires is expiration date– Delete cookie by setting “expires” to date in past

• HttpOnly Flag: cookie cannot be accessed by Javascript, but only sent by browser– Prevents XSS, not CSRF from stealing cookies

HTTP-Only Cookie

Cookie Policy

Given site A. Rules based on cookie scope:

1. Which cookies can be set?– Cookies with domain-suffix (aka super domain) of

site A (except TLD)

2. Which cookies can be received?– Cookies with domain-suffix (aka super domain) and

path prefix of site A

– Check flags as well

Cookie Policy

• 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

GET …


Server

Browser

Server Sets Cookies

domain: any domain-suffix of URL-hostname, except TLDpath: can be set to anything

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

allowed domainslogin.site.com

.site.com

disallowed domainsuser.site.comothersite.com

.com

[top-level domains, e.g. ‘.com’]

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

Web Server Sets Cookie

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

domain

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

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

Web Server Sets Cookie Example

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:

Web Server Sets Cookie Example

• A cookie can be accessed in mostly two ways:

– When a user visits a site, the user’s browser

sends automatically relevant cookies

– Javascript can access it via document.cookie

Receiving Cookies

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 has “Secure” flag set]

GET //URL-domain/URL-pathCookie: NAME = VALUE

Server

Goal: server only sees cookies in its scope

Browser

Browser Sends Cookie

cookie 1name = useridvalue = u1domain = login.site.compath = /non-secure

cookie 2name = useridvalue = u2domain = .site.compath = /non-secure

http://checkout.site.com/

http://login.site.com/

http://othersite.com/

cookie: userid=u2

cookie: userid=u1, userid=u2

cookie: none

Browser Sends Cookie Example


cookie 2name = useridvalue = u2domain = .site.compath = /secretnon-secure

http://checkout.site.com/secret/treasure


http://othersite.com/secret

cookie: userid=u2

cookie: userid=u1

cookie: none


http://checkout.site.com/http://login.site.com/https://login.site.com/

cookie 1name = useridvalue = u1domain = login.site.compath = /secure

cookie 2name = useridvalue = u2domain = .site.compath = /non-secure

cookie: userid=u2

cookie: userid=u2

cookie: userid=u1; userid=u2(arbitrary order)


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

document.cookie often used to customize page in Javascript

Client Reads Cookie

Cookie Policy versus Same-Origin Policy

Recall: Same-Origin Policy

• Granularity of protection for same origin policy• Origin = protocol + hostname + port

http://coolsite.com:81/tools/info.html

protocol hostname port

• Origin is determined by string matching! If these match, it is same origin, else it is not.

• 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

Cookie Policy vs SOP


cookie 2name = useridvalue = u2domain = .site.compath = /non-secureHttp-Only

http://checkout.site.com/


http://othersite.com/

cookie: none

cookie: userid=u1

cookie: none

JS on each of these URLs can access all cookies that would be sent for that URL if the httpOnly flag is not set

Cookie Policy vs SOP Example

• 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

Indirectly Bypassing SOP using Cookie Policy

financial.example.comweb server

blog.example.comweb server

(assume attacker compromised this web server)

Victim user browser

financial.example.com

cookie jar for *.example.com

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 group domains.

blog.example.com

Cookie domains:





Victim user browser

financial.example.com


blog.example.com

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





Victim user browser

example.com


example.com

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



Victim user browser

example.com


example.com

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?


• 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 bypassed same-origin policy (indirectly) because blog.example.com influenced financial.example.com


• 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

RFC6265

Break Time: Ruta Jawale

• Got stuck under the Swiss Alps

Session Management

• A sequence of requests and responses fromone browser to one (or more) sites– Session can be long (Gmail - two weeks)

or short

– without session management:

• Session management:– Authorize user once;– All subsequent requests are tied to user

users would have to constantly re-authenticate

Sessions

HTTP request: GET /index.html

HTTP response contains: WWW-Authenticate: Basic realm="Password Required“

Browsers sends hashed password on all subsequent HTTP requests: Authorization: Basic ZGFddfibzsdfgkjheczI1NXRleHQ=

One username and password for a group of users

Historical: HTTP Authentication

• Hardly used in commercial sites

– User cannot log out other than by closing browser• What if user has multiple accounts?• What if multiple users on same computer?

– Site cannot customize password dialog

– Confusing dialog to users

– Easily spoofed

HTTP Authentication Problems

Browser Web SiteGET /index.html

set anonymous session token

GET /books.htmlanonymous session token

POST /do-loginUsername & password

elevate to a logged-in session token

POST /checkoutlogged-in session token

check credentials

Validatetoken

Session Tokens

• Browser cookie:Set-Cookie: SessionToken=fduhye63sfdb

• Embed in all URL links:https://site.com/checkout ?

SessionToken=kh7y3b

• In a hidden form field: <input type=“hidden” name=“sessionid”

value=“kh7y3b”>

Storing Session Tokens

• Browser cookie:browser sends cookie with every request,

even when it should not (CSRF)

• Embed in all URL links:token leaks via HTTP Referer header

users might share URLs

• In a hidden form field: short sessions only

Better answer: a combination of all of the above (e.g., browser cookie with CSRF protection using form secret tokens)

Storing Session Tokens

Cross-Site Request Forgery (CSRF)

Top 10 web vulnerabilities

• Allow a user to provide some data which gets sent with an HTTP POST request to a server

<form action="bank.com/action.php"> First name: <input type="text"

name="firstname"> Last name:<input type="text"

name="lastname"> <input type="submit"

value="Submit"></form>

HTTP POST request bank.com/action.php?firstname=Alice&lastname=Smith

When filling in Alice and Smith, and clicking submit, the browser issues

As always, the browser attaches relevant cookies

HTML Forms

• Server assigns a session token to each user after they logged in, places it in the cookie

• The server keeps a table of username to current session token, so when it sees the session token it knows which user

Consider: Cookie Stores Session Token

ServerBrowser

POST/login.cgi

Set-cookie: session token

GET/POST…Cookie: session token

response

Cookie Stores Session Token

Attack Server

Server Victim bank.com

User Victim

establish session

send forged request

visit server receive malicious page

1

2

3

4 (w/ cookie)

cookie for bank.comwith session token

What can go bad? URL contains transaction action


• Example: – User logs in to bank.com

• Session cookie remains in browser state

– User visits malicious site containing: <form name=F action=http://bank.com/BillPay.php> <input name=recipient value=badguy> … <script> document.F.submit(); </script>

– Browser sends user auth cookie with request• Transaction will be fulfilled

• Problem: – cookie auth is insufficient when side effects occur


User credentials

Cookie: SessionID=523FA4cd2E


An attacker could • add videos to a user’s "Favorites," • add himself to a user’s "Friend" or "Family" list, • send arbitrary messages on the user’s behalf, • flagged videos as inappropriate, • automatically shared a video with a user’s contacts,

subscribed a user to a "channel" (a set of videos published by one person or group), and

• added videos to a user’s "QuickList" (a list of videos a user intends to watch at a later point).

2008 CSRF attack

CSRF Defense

• CSRF token

• Referer Validation

• Origin Header Validation– See discussion

• Others (e.g., custom HTTP Header)

<input type=hidden value=23a3af01b>

Referer: http://www.facebook.com/home.php

CSRF Defense

1. goodsite.com server wants to protect itself, so it includes a secret token into the webpage (e.g., in forms as a hidden field)

2. Requests to goodsite.com include the secret 3. goodsite.com server checks that the token embedded in

the webpage is the expected one; reject request if not

Can the token be?

• 123456

• Dateofbirth

No, CSRF token must be hard to guess by the attacker

CSRF Token

● The server stores state that binds the user's CSRF token to the user's session id

● Embeds CSRF token in every form

● On every request the server validates that the supplied CSRF token is associated with the user's session id

● Disadvantage is that the server needs to maintain a large state table to validate the tokens.

CSRF Token

• When the browser issues an HTTP request, it includes a referer header that indicates which URL initiated the request– Referer header could be used to distinguish

between same site request and cross site request

Referer Validation

Referer Validation

• HTTP Referer header– Referer: http://www.facebook.com/– Referer: http://www.attacker.com/evil.html– Referer:

• Strict policy disallows (secure, less usable)• Lenient policy allows (less secure, more usable)

✔��?

Referer Validation

Privacy Issues with Referer header:• The referer contains sensitive information that

impinges on the privacy• The referer header reveals contents of the

search query that lead to visit a website.• Some organizations are concerned that

confidential information about their corporate intranet might leak to external websites via Referer header

Privacy Issue: Referer Validation

• Referer may leak privacy-sensitive information

http://intranet.corp.apple.com/

projects/iphone/competitors.html

• Common sources of blocking:– Network stripping by the organization– Network stripping by local machine– Stripped by browser for HTTPS -> HTTP transitions– User preference in browser

Privacy Issue: Referer Validation

• Cookies add state to HTTP– Cookies are used for session management– They are attached by the browser automatically to

HTTP requests• CSRF attacks execute request on benign site

because cookie is sent automatically• Defenses for CSRF:

– embed unpredicatable token and check it later– check referer header

Summary

Web Security: Session management and CSRFcs161/su19/lectures/lec21_web_4.pdfweb server...

Documents

Transcript of Web Security: Session management and CSRFcs161/su19/lectures/lec21_web_4.pdfweb server...