web security: session management and csrfcs161/sp18/slides/4.5... · 2018-04-07 · owasp top 10...

Web Security: Session management and CSRF

CS 161: Computer SecurityProf. Raluca Ada Popa

April 5, 2018

Credit: this deck is a combination of my slides and slide adaptations from previous offerings of this course and from CS 241 of Prof. Dan Boneh

Cookie policy versus same-origin policy

Cookie policy: when browser sends cookie

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

Server

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

Cookie policy versus same-origin policy

Consider Javascript on a page loaded from a URL UIf 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.

Examples

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=u2cookie: userid=u1, userid=u2cookie: 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

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 policyIdeas how?

Example

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

Example




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

Example




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

Example


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?

Indirectly bypassing same-origin policy using cookie policy

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

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

Session management

SessionsA sequence of requests and responses fromone browser to one (or more) sitesn Session can be long (Gmail - two weeks)

or short

n without session mgmt:

Session mgmt:n Authorize user once;n All subsequent requests are tied to user

users would have to constantly re-authenticate

Pre-history: HTTP auth

HTTP request: GET /index.htmlHTTP 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

HTTP auth problemsHardly used in commercial sites

n User cannot log out other than by closing browserw What if user has multiple accounts?w What if multiple users on same computer?

n Site cannot customize password dialog

n Confusing dialog to users

n Easily spoofed

Session tokensBrowser Web Site

GET /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(later)

Validatetoken

Storing session tokens: Lots of options (but none are perfect)

• Browser cookie:Set-Cookie: SessionToken=fduhye63sfdb

• Embedd 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: problems• Browser cookie:

browser sends cookie with every request,even when it should not (CSRF)

• Embed in all URL links:token leaks via HTTP Referer headerusers 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)

Cross Site Request Forgery

Top web vulnerabilities

21

What Changed From 2010 to 2013?

The threat landscape for applications security constantly changes. Key factors in this evolution are advances made by attackers, the release of new technologies with new weaknesses as well as more built in defenses, and the deployment of increasingly complex systems. To keep pace, we periodically update the OWASP Top 10. In this 2013 release, we made the following changes: 1) Broken Authentication and Session Management moved up in prevalence based on our data set. We believe this is probably

because this area is being looked at harder, not because these issues are actually more prevalent. This caused Risks A2 and A3 to switch places.

2) Cross-Site Request Forgery (CSRF) moved down in prevalence based on our data set from 2010-A5 to 2013-A8. We believe this is because CSRF has been in the OWASP Top 10 for 6 years, and organizations and framework developers have focused on it enough to significantly reduce the number of CSRF vulnerabilities in real world applications.

3) We broadened Failure to Restrict URL Access from the 2010 OWASP Top 10 to be more inclusive:

+ 2010-A8: Failure to Restrict URL Access is now 2013-A7: Missing Function Level Access Control – to cover all of function level access control. There are many ways to specify which function is being accessed, not just the URL.

4) We merged and broadened 2010-A7 & 2010-A9 to CREATE: 2013-A6: Sensitive Data Exposure:

– This new category was created by merging 2010-A7 – Insecure Cryptographic Storage & 2010-A9 - Insufficient Transport Layer Protection, plus adding browser side sensitive data risks as well. This new category covers sensitive data protection (other than access control which is covered by 2013-A4 and 2013-A7) from the moment sensitive data is provided by the user, sent to and stored within the application, and then sent back to the browser again.

5) We added: 2013-A9: Using Known Vulnerable Components:

+ This issue was mentioned as part of 2010-A6 – Security Misconfiguration, but now has a category of its own as the growth and depth of component based development has significantly increased the risk of using known vulnerable components.

OWASP Top 10 – 2010 (Previous) OWASP Top 10 – 2013 (New)

A1 – Injection A1 – Injection

A3 – Broken Authentication and Session Management A2 – Broken Authentication and Session Management

A2 – Cross-Site Scripting (XSS) A3 – Cross-Site Scripting (XSS)

A4 – Insecure Direct Object References A4 – Insecure Direct Object References

A6 – Security Misconfiguration A5 – Security Misconfiguration

A7 – Insecure Cryptographic Storage – Merged with A9 Æ A6 – Sensitive Data Exposure

A8 – Failure to Restrict URL Access – Broadened into Æ A7 – Missing Function Level Access Control

A5 – Cross-Site Request Forgery (CSRF) A8 – Cross-Site Request Forgery (CSRF)

<buried in A6: Security Misconfiguration> A9 – Using Known Vulnerable Components

A10 – Unvalidated Redirects and Forwards A10 – Unvalidated Redirects and Forwards

A9 – Insufficient Transport Layer Protection Merged with 2010-A7 into new 2013-A6

Release Notes RN























Release Notes RN























Release Notes RN























Release Notes RN

HTML FormsAllow 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

Consider cookie storing session token

Server assigns a session token to each user after they logged in, places it in the cookieThe server keeps a table of username to current session token, so when it sees the session token it knows which user

Session using cookies

ServerBrowser

Basic picture

Attack Server

Server Victim bank.com

User Victim

1

2

4

cookie for bank.comwith session token

What can go bad? URL contains transaction action

Cross Site Request Forgery (CSRF)Example: n User logs in to bank.com

w Session cookie remains in browser state

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

n Browser sends user auth cookie with requestw Transaction will be fulfilled

Problem: n cookie auth is insufficient when side effects occur

Form post with cookie

User credentials

Cookie: SessionID=523FA4cd2E

Squigler demo

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

Defenses

ideas?

CSRF DefensesCSRF token

Referer Validation

Others (e.g., custom HTTP Header) we won’t go into

<input type=hidden value=23a3af01b>

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

CSRF token1. 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

CSRF token must be hard to guess by the attacker

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

How token is used

– When the browser issues an HTTP request, it includes a referer header that indicates which URL initiated the request

– This information in the Referer header could be used to distinguish between same site request and cross site request

Other CRSF protection: Referer Validation

Referer Validation

Referer Validation DefenseHTTP Referer headern Referer: http://www.facebook.com/n Referer: http://www.attacker.com/evil.htmln Referer:

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

üû?

! 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 Issues with Referer header

Referer Privacy ProblemsReferer may leak privacy-sensitive information

http://intranet.corp.apple.com/projects/iphone/competitors.html

Common sources of blocking:n Network stripping by the organizationn Network stripping by local machinen Stripped by browser for HTTPS -> HTTP transitionsn User preference in browser

Summary: sessions and CSRFCookies add state to HTTPn Cookies are used for session managementn They are attached by the browser automatically to

HTTP requestsCSRF attacks execute request on benign site because cookie is sent automaticallyDefenses for CSRF: n embed unpredicatable token and check it latern check referer header

web security: session management and csrfcs161/sp18/slides/4.5... · 2018-04-07 · owasp top 10...

Documents