Vitaly Shmatikov

1
Security of Web Applications
CS 380S

• Vitaly Shmatikov

2
Reading Assignment

• Cross-Site Scripting Explained and Advanced
  SQL Injection

3
Browser and Network
Network
request
Browser
website
reply
OS
Hardware
4
HTTP HyperText Transfer Protocol

• Used to request and return data
• Methods GET, POST, HEAD,
• Stateless request/response protocol
• Each request is independent of previous requests
• Statelessness has a significant impact on design
  and implementation of applications

5
Storing Info Across Sessions

• A cookie is a file created by an Internet site to
  store information on your computer

Enters form data
Server
Browser
Stores cookie
Includes domain (who can read it), expiration,
secure (can be read only over SSL)
Requests cookie
Server
Browser
Returns data
HTTP is a stateless protocol cookies add state
6
What Are Cookies Used For?

• Authentication
• Use the fact that the user authenticated
  correctly in the past to make future
  authentication quicker
• Personalization
• Recognize the user from a previous visit
• Tracking
• Follow the user from site to site learn his/her
  browsing behavior, preferences, and so on

7
Cookie Management

• Cookie ownership
• Once a cookie is saved on your computer, only the
  website that created the cookie can read it
• Variations
• Temporary cookies
• Stored until you quit your browser
• Persistent cookies
• Remain until deleted or expire
• Third-party cookies
• Originates on or sent to another website

8
Web Authentication via Cookies

• Need authentication system that works over HTTP
  and does not require servers to store session
  data
• Why is it a bad idea to store session state on
  server?
• Servers can use cookies to store state on client
• After client successfully authenticates, server
  computes an authenticator and gives it to browser
  in a cookie
• Client cannot forge authenticator on his own
• Example hash(servers secret key, session id)
• With each request, browser presents the cookie
• Server recomputes and verifies the authenticator
• Server does not need to remember the authenticator

9
Typical Session with Cookies
client
server
POST /login.cgi
Verify that this client is authorized
Set-Cookieauthenticator
GET /restricted.html Cookieauthenticator
Check validity of authenticator (e.g.,
recompute hash(key,sessId))
Restricted content
Authenticators must be unforgeable and
tamper-proof (malicious client shouldnt be able
to compute his own or modify an existing
authenticator)
10
Web Applications

• Online banking, shopping, government, etc. etc.
• Website takes input from user, interacts with
  back-end databases and third parties, outputs
  results by generating an HTML page
• Often written from scratch in a mixture of PHP,
  Java, Perl, Python, C, ASP
• Security is rarely the main concern

11
Typical JavaScript
Script defines a page-specific function

• function whichButton(event)
• if (event.button1)
• alert("You clicked the left mouse button!")
• else
• alert("You clicked the right mouse button!")

Function gets executed when some event happens
(onLoad, onKeyPress, onMouseMove)
12
JavaScript Security Model

• Script runs in a sandbox
• Not allowed to access files or talk to the
  network
• 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

13
Risks of Poorly Written Scripts

• For example, echo users input
• http//naive.com/search.php?termBritney Spears
• search.php responds with
• Search results
• You have searched for _GETterm ?
• Or
• GET/ hello.cgi?nameBob
• hello.cgi responds with
• Welcome, dear Bob

14
XSS Cross-Site Scripting
victims browser
naive.com
evil.com
E.g., URL embedded in HTML email
hello.cgi
hello.cgi executed
Forces victims browser to call hello.cgi on
naive.com with this script as name
15
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 the
  attack script and the users browser to execute
  arbitrary operations contained in the attack
  script
• Can transmit users private data to attacker
• E.g., encode it in a URL request to attackers
  site
• Can change contents of the affected website
• Show bogus information, request sensitive data
• Can cause users browser to attack other websites

16
MySpace Worm (1)
http//namb.la/popular/tech.html

• Users can post HTML on their MySpace pages
• MySpace does not allow scripts in users HTML
• No , , onclick, hrefjavascript//
• but does allow tags for CSS. K00L!
• But MySpace will strip out javascript
• Use javascript instead
• But MySpace will strip out quotes
• Convert from decimal instead
• alert('double quote ' String.fromCharCode(34
  ))

17
MySpace Worm (2)
http//namb.la/popular/tech.html

• There were a few other complications and things
  to get around. This was not by any means a
  straight forward process, and none of this was
  meant to cause any damage or piss anyone off.
  This was in the interest of..interest. It was
  interesting and fun!
• Started on samy MySpace page
• Everybody who visits an infected page, becomes
  infected and adds samy as a friend and hero
• 5 hours later samy
• has 1,005,831 friends
• Was adding 1,000 friends
• per second at its peak

18
Where Malicious Scripts Live

• Hide script 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
• http//cnn.com/login?URIAttackScriptscript
• Use phishing email to drive users to this URL
• Similar malicious DOM (client parses bad URL)

Attack code does not appear in HTML sent over
network
19
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
• javascriptalert(Welcome to paradise!)
• Runs in the context of current loaded page

20
Preventing Cross-Site Scripting

• Preventing injection of scripts into HTML is
  hard!
• Blocking is not enough
• Event handlers, stylesheets, encoded inputs
  (3C), etc.
• phpBB allowed simple HTML tags like
• onmouseoverscript xHello
• 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)

21
Inadequate Input Validation

• http//victim.com/copy.php?nameusername
• copy.php includes
• system(cp temp.dat
  name.dat)
• User calls
• http//victim.com/copy.php?namea rm
• copy.php executes
• system(cp temp.dat a rm
  )

Supplied by the user!
22
User Data in SQL Queries

• set UserFoundexecute(
• 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
23
SQL Injection

• User gives username ' OR 11 --
• Web server executes query
• set UserFoundexecute(
• SELECT FROM UserTable WHERE
• username' ' OR 11 -- )
• This returns the entire database!
• UserFound.EOF is always false authentication is
  always correct

Always true!
Everything after -- is ignored!
24
Another SQL Injection Example
From Kevin Mitnicks The Art of Intrusion

• To authenticate logins, server runs this SQL
  command against the user database
• SELECT WHERE username AND pwdpasswd
• 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!)

Wildcard matches any password
25
It Gets Better

• User gives username
• ' exec cmdshell net user badguy badpwd /
  ADD --
• Web server executes query
• set UserFoundexecute(
• SELECT FROM UserTable WHERE
• username' ' exec -- )
• Creates an account for badguy on DB server
• Fix always escape user-supplied arguments
• Convert into \

26
Uninitialized Inputs

• / php-files/lostpassword.php /
• for (i0 i
• new_pass . chr(rand(97,122))
• result dbquery(UPDATE .db_prefix.users
• SET user_passwordmd5(new_pass)
• WHERE user_id.datauser_id. )
• In normal execution, this becomes
• UPDATE users SET user_passwordmd5(????????)
• WHERE user_iduserid

Creates a password with 8 random characters,
assuming new_pass is set to NULL
SQL query setting password in the DB
27
Exploit

• User appends this to the URL
• new_passbadPwd27292c
• user_level27103272cuser_aim2827
• SQL query becomes
• UPDATE users SET user_passwordmd5(badPwd)
• user_level103, user_aim(????????
  )
• WHERE user_iduserid

This sets new_pass to badPwd),
user_level103, user_aim(
Users password is set to badPwd
with superuser privileges
28
Exploits of a Mom
http//xkcd.com/327/