1 Web Security: part 1. Vulnerability Stats: web is “winning” Source: MITRE CVE trends Majority of vulnerabilities now found in web software.

Slides:



Advertisements
Similar presentations
Cross-Site Scripting Issues and Defenses Ed Skoudis Predictive Systems © 2002, Predictive Systems.
Advertisements

Nick Feamster CS 6262 Spring 2009
Cookie Same Origin Policy Dan Boneh CS 142 Winter 2009 Monday: session management using cookies.
ForceHTTPS: Protecting High-Security Web Sites from Network Attacks Collin Jackson and Adam Barth.
HTTPS and the Lock Icon Dan Boneh. Goals for this lecture Brief overview of HTTPS: How the SSL/TLS protocol works (very briefly) How to use HTTPS Integrating.
Chapter 17: WEB COMPONENTS
EECS 354 Network Security Cross Site Scripting (XSS)
CMSC 414 Computer and Network Security Lecture 24 Jonathan Katz.
HTTP HyperText Transfer Protocol. HTTP Uses TCP as its underlying transport protocol Uses port 80 Stateless protocol (i.e. HTTP Server maintains no information.
Web Servers How do our requests for resources on the Internet get handled? Can they be located anywhere? Global?
How the web works: HTTP and CGI explained
1 Secure Web Site Design Dan Boneh CS 155 Spring 2007 Project 2: out today.
The World Wide Web and the Internet Dr Jim Briggs 1WUCM1.
1 Secure Web Site Design Dan Boneh CS 155 Spring 2006.
Web Security: Session Management
Lecture 16 Page 1 CS 236 Online Cross-Site Scripting XSS Many sites allow users to upload information –Blogs, photo sharing, Facebook, etc. –Which gets.
Cookies COEN 351 E-commerce Security. Client / Session Identification HTTP does not maintain state. State Information can be passed using: HTTP Headers.
Subspace: Secure Cross-Domain Communication for Web Mashups In Proceedings of the 16th International World Wide Web Conference. (WWW), 2007 Collin Jackson,
Introduction to InfoSec – Recitation 10 Nir Krakowski (nirkrako at post.tau.ac.il) Itamar Gilad (itamargi at post.tau.ac.il)
More on web security. Reported vulnerabilities “in the wild” Data from aggregator and validator of NVD-reported vulnerabilities.
Web Security Slides from John Mitchell and Vitaly Shmatikov (Modified by Vijay Ganesh) ECE458Winter 2013.
Web technologies and programming cse hypermedia and multimedia technology Fanis Tsandilas April 3, 2007.
FALL 2005CSI 4118 – UNIVERSITY OF OTTAWA1 Part 4 Web technologies: HTTP, CGI, PHP,Java applets)
Copyright© 2002 Avaya Inc. All rights reserved Advanced Cross Site Scripting Evil XSS Anton Rager.
HTTP and Server Security James Walden Northern Kentucky University.
Cross-Site Scripting Vulnerabilities Adam Doupé 11/24/2014.
CHAPTER 12 COOKIES AND SESSIONS. INTRO HTTP is a stateless technology Each page rendered by a browser is unrelated to other pages – even if they are from.
Prevent Cross-Site Scripting (XSS) attack
Web Security Borrowed from John Mitchell, Stanford.
© Neeraj Suri EU-NSF ICT March 2006 DEWSNet Dependable Embedded Wired/Wireless Networks MUET Jamshoro Browser Security Model Faisal Karim Shaikh DEWSNet.
FTP (File Transfer Protocol) & Telnet
Ladd Van Tol Senior Software Engineer Security on the Web Part One - Vulnerabilities.
CP476 Internet Computing Lecture 5 : HTTP, WWW and URL 1 Lecture 5. WWW, HTTP and URL Objective: to review the concepts of WWW to understand how HTTP works.
2: Application Layer1 CS 4244: Internet Software Development Dr. Eli Tilevich.
Robust Defenses for Cross-Site Request Forgery CS6V Presented by Saravana M Subramanian.
JavaScript, Fourth Edition
November 13, 2008 Ohio Information Security Forum Attack Surface of Web Applications James Walden Northern Kentucky University
Working with Cookies Managing Data in a Web Site Using JavaScript Cookies* *Check and comply with the current legislation regarding handling cookies.
1 Internet Browsing Vulnerabilities and Security ECE4112 Final Lab Ye Yan Frank Park Scott Kim Neil Joshi.
20-753: Fundamentals of Web Programming Copyright © 1999, Carnegie Mellon. All Rights Reserved. 1 Lecture 7: HTTP and CGI Fundamentals of Web Programming.
Chapter 8 Cookies And Security JavaScript, Third Edition.
Web Engineering we define Web Engineering as follows: 1) Web Engineering is the application of systematic and proven approaches (concepts, methods, techniques,
Top Five Web Application Vulnerabilities Vebjørn Moen Selmersenteret/NoWires.org Norsk Kryptoseminar Trondheim
Robust Defenses for Cross-Site Request Forgery
1 Welcome to CSC 301 Web Programming Charles Frank.
1 Robust Defenses for Cross-Site Request Forgery Adam Barth, Collin Jackson, John C. Mitchell Stanford University 15th ACM CCS.
Cookies and Sessions IDIA 618 Fall 2014 Bridget M. Blodgett.
A Little Bit About Cookies Fort Collins, CO Copyright © XTR Systems, LLC A Little Bit About Cookies Instructor: Joseph DiVerdi, Ph.D., M.B.A.
Lecture 16 Page 1 CS 236 Online Web Security CS 236 On-Line MS Program Networks and Systems Security Peter Reiher.
Cookies COEN 351 E-commerce Security. Client / Session Identification HTTP Headers Client IP Address HTTP User Login FAT URLs Cookies.
University of Central Florida The Postman Always Rings Twice: Attacking & Defending postMessage in HTML5 Websites Ankur Verma University of Central Florida,
ECMM6018 Enterprise Networking for Electronic Commerce Tutorial 7
5 th ed: Chapter 17 4 th ed: Chapter 21
Overview of Servlets and JSP
1 Web Security: part 1. Vulnerability Stats: web is “winning” Source: MITRE CVE trends Majority of vulnerabilities now found in web software.
Web Application (In)security Note: Unless noted differently, all scanned figures were from the textbook, Stuttard & Pinto, 2011.
PHP Security Ryan Dunn Jason Pack. Outline PHP Overview PHP Overview Common Security Issues Common Security Issues Advanced Security Issues Advanced Security.
Session Management Tyler Moore CS7403 University of Tulsa Slides adapted in part or whole from Dan Boneh, Stanford CS155 1.
COMP2322 Lab 2 HTTP Steven Lee Jan. 29, HTTP Hypertext Transfer Protocol Web’s application layer protocol Client/server model – Client (browser):
Session 11: Cookies, Sessions ans Security iNET Academy Open Source Web Development.
By Collin Donaldson. Hacking is only legal under the following circumstances: 1.You hack (penetration test) a device/network you own. 2.You gain explicit,
Browser Security Model *original slides by prof. John Mitchell.
SlideSet #20: Input Validation and Cross-site Scripting Attacks (XSS) SY306 Web and Databases for Cyber Operations.
Web Security (cont.) 1. Referral issues r HTTP referer (originally referrer) – HTTP header that designates calling resource  Page on which a link is.
World Wide Web policy.
CSC 495/583 Topics of Software Security Web Browser Security (2)
What is Cookie? Cookie is small information stored in text file on user’s hard drive by web server. This information is later used by web browser to retrieve.
John Mitchell (based on Dan’s previous slides)
Cross Site Request Forgery (CSRF)
Presentation transcript:

1 Web Security: part 1

Vulnerability Stats: web is “winning” Source: MITRE CVE trends Majority of vulnerabilities now found in web software

Web security: two sides Web browser (this and next lecture) Can be attacked by any web site it visits Attacks result in:  Malware installation (keyloggers, bot-nets)  Document theft from corporate network  Loss of private data Web application code: (next Thursday) Runs at web site, e.g. banks, e-merchants, blogs Written in PHP, ASP, JSP, Ruby, … Many potential bugs: XSS, XSRF, SQL injection Attacks lead to stolen CC#, defaced sites, mayhem

Web Threat Models Web attacker Control attacker.com Can obtain SSL/TLS certificate for attacker.com ($0) User visits attacker.com Network attacker Passive: Wireless eavesdropper Active: Evil router, DNS poisoning Malware attacker Attacker escapes browser sandbox

Malware attacker Browsers (like any software) contain exploitable bugs Often enable remote code execution by web sites Google study: [the ghost in the browser 2007]  Found Trojans on 300,000 web pages (URLs)  Found adware on 18,000 web pages (URLs) NOT OUR FOCUS THIS WEEK Today: even if browsers were bug-free, still lots of vulnerabilities on the web

Microsoft Security Bulletin MS06-013, April 2006

Malware distribution Via vulnerable web servers: Powered by … Via ad networks: User visits a reputable web site containing banner ad  Banner ad hosted in iframe from 3 rd party site  3 rd party serves ad exploiting browser bug  often involves 4 th and 5 th parties Example: feb. 2008:  ad serves PDF file that exploits adobe reader bug  Installs Zonebac: modifies search engine results

8 Security User Interface

Address Bar Where this page came from But not where the embedded content came from awglogin

URLs Global identifiers of network-retrievable documents Example: Special characters are encoded as hex: %0A = newline %20 or + = space, %2B = + (special exception) Protocol Hostname Port Path Query Fragment

GET /index.html HTTP/1.1 Accept: image/gif, image/x-bitmap, image/jpeg, */* Accept-Language: en User-Agent: Mozilla/1.22 (compatible; MSIE 2.0; Windows 95) Connection: Keep-Alive Host: HTTP Request MethodFileHTTP versionHeaders Data – none for GET Blank line GET: no side effect. POST: possible side effect.

HTTP/ OK Date: Sun, 21 Apr :20:42 GMT Server: Microsoft-Internet-Information-Server/5.0 Connection: keep-alive Content-Type: text/html Last-Modified: Thu, 18 Apr :39:05 GMT Content-Length: 2543 Some data... blah, blah, blah HTTP Response HTTP versionStatus codeReason phrase Headers Data

Mixed Content: HTTP and HTTPS Page loads over HTTPS, but contains content over HTTP IE: displays mixed-content dialog to user Flash files over HTTP are loaded with no warning (!) Note: Flash can script the embedding page Firefox: displays a red slash over lock icon (no dialog) Flash files over HTTP do not trigger the slash Safari: does not attempt to detect mixed content

Mixed Content: HTTP and HTTPS silly dialogs

Mixed content and network attacks banks: after login all content served over HTTPS Developer error: Somewhere on bank site write Active network attacker can now hijack any session Better way to include content: served over the same protocol as embedding page

Lock Icon 2.0 Extended validation (EV) certs Prominent security indicator for EV certificates note: EV site loading content from non-EV site does not trigger mixed content warning

Picture-in-picture attacks Trained users are more likely to fall victim to this [JSTB’07]

Finally: the status Bar Trivially spoofable <a href=“ onclick=“this.href = ‘ PayPal

19 Same Origin Policy

Document Object Model (DOM) Object-oriented interface used to read and write docs web page in HTML 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) Also Browser Object Model (BOM) window, document, frames[], history, location, navigator (type and version of browser)

Browser Same Origin Policy (SOP) Applies to: Cookies: cookie from origin A not visible to origin B DOM: script from origin A cannot read or set properties for origin B For DOM access, two origins are the same iff ( domain-name, port, and protocol ) are equal Safari note: until 3.0 SOP was only (domain-name, port) Web sites from different domains cannot interact except in very limited ways

SOP Examples Example HTML at Disallowed access: alert( frames[0].contentDocument.body.innerHTML ) alert( frames[0].src ) Allowed access: alert( images[0].height ) Navigating child frame is allowed (but reading frame[0].src is not): frames[0].location.href = “

document.domain Setting document.domain changes origin of page Can only be set to suffix of domain name checkout.shop.com  shop.com login.shop.com  shop.com shop.com: to join “origin” shop.com must do: document.domain = document.domain Origin is actually the tuple same origin

Web Browser: the new OS Origins are “similar” to processes One origin should not interfere with another Cooperation: often sites want to communicate Google AdSense: Mash-ups Gadget aggregators (e.g. iGoogle or live.com) To communicate with B, site A must give B full control: now script from site B runs in origin of site A

Mashups

iGoogle

Windows Live.com

28 Network access from browser sandbox Send anywhere (but some ports are inaccessible, e.g. SMTP ) Read response only from your origin

Same Origin Requests with XMLHttpRequet var xhr = new XMLHttpRequest(); xhr.open("POST", " true); // asynchronous xhr.send("Hello world!"); xhr.onload = function() { if (xhr.status == 200) { alert(xhr.responseText); } prepare request read response

Sending a Cross-Domain GET Data must be URL encoded Browser sends: GET file.cgi?foo=1&bar=x%20y HTTP/1.1 Host: othersite.com … Can’t send to some restricted ports, like 25 (SMTP) Denial of Service (DoS) using GET: a popular site can DoS another site [Puppetnets ’06]

Sending a Cross-Domain POST document.forms[0].submit() Hidden iframe can do this in background  user visits a malicious page, browser submits form on behalf of user  e.g. page re-programs user’s home router ( XSRF ) Can’t send to some restricted ports, like 25 (SMTP) submit post

32 Cookies: client state

Cookies Used to store state on user’s machine Browser Server GET … HTTP Header: Set-cookie:NAME=VALUE ; domain = (who can read) ; expires = (when expires) ; secure = (only over SSL) Browser Server GET … Cookie: NAME = VALUE HTTP is stateless protocol; cookies add state If expires=NULL: this session only

Cookie authentication Browser Web ServerAuth server POST login.cgi Username & pwd Validate user auth=val Store val Set-cookie: auth=val GET restricted.html Cookie: auth=val restricted.html auth=val YES/NOIf YES, restricted.html Check val

Weak authenticators: security risk Predictable cookie authenticator Verizon Wireless - counter  user logs in, gets counter, can view sessions of other users Weak authenticator generation: [Fu et al. ’01] WSJ.com:cookie = {user, MAC k (user) } Weak MAC exposes K from few cookies. Apache Tomcat: generateSessionID() MD5(PRNG) … but weak PRNG [GM’05]. Predictable SessionID’s

Cookie Security Policy Uses: User authentication Personalization User tracking: e.g. Doubleclick (3 rd party cookies) Browser will store: At most 20 cookies/site, 3 KB / cookie Origin is the tuple Can set cookies valid across a domain suffix

Secure Cookies Browser Server GET … HTTP Header: Set-cookie:NAME=VALUE ; Secure=true Provides confidentiality against network attacker Browser will only send cookie back over HTTPS … but no integrity Can rewrite secure cookies over HTTP  network attacker can rewrite secure cookies  can log user into attacker’s account

httpOnly Cookies Browser Server GET … HTTP Header: Set-cookie:NAME=VALUE ; httpOnly Cookie sent over HTTP(s), but not accessible to scripts cannot be read via document.cookie Helps prevent cookie theft via XSS … but does not stop most other risks of XSS bugs.

Storing data on browser? Unreliable: – User can change/clear values – Silly example: Shopping cart software Set-cookie:shopping-cart-total = 150 ($) – User edits cookie file (cookie poisoning): Cookie:shopping-cart-total = 15 ($) Similar to problem with hidden fields 39

40 Not so silly … (as of 2/2000) D3.COM Pty Ltd: ShopFactory Adgrafix: Check It Out Baron Consulting Group: WebSite Tool ComCity Corporation: SalesCart Crested Butte Software: EasyCart Dansie.net: Dansie Shopping Cart Intelligent Vending Systems: Intellivend Make-a-Store: Make-a-Store OrderPage McMurtrey/Whitaker & Associates: Cart CartMan 1.04 Rich Media Technologies: JustAddCommerce 5.0 SmartCart: SmartCart Web Express: Shoptron 1.2 Source:

41 Solution When storing state on browser, MAC data using server secret key.NET 2.0: – System.Web.Configuration.MachineKey  Secret web server key intended for cookie protection – HttpCookie cookie = new HttpCookie(name, val); HttpCookie encodedCookie = HttpSecureCookie.Encode (cookie); – HttpSecureCookie.Decode (cookie);

42 Frames and frame busting

<iframe name=“myframe” src=“ This text is ignored by most browsers. Frames Embed HTML documents in other documents

Frame Busting Goal: prevent web page from loading in a frame example: opening login page in a frame will display correct passmark image Frame busting: if (top != self) top.location.href = location.href

Correct Frame Busting Problem: Javascript OnUnload event Correct frame busting: if (top != self) top.location.href = location.href else { … code of page here …}

46 THE END