CS526: Information security

Similar documents
Information Security CS 526 Topic 8

Information Security CS 526 Topic 11

Computer Security CS 426 Lecture 41

CIS 5373 Systems Security

CIS 5373 Systems Security

Computer and Network Security

CIS 551 / TCOM 401 Computer and Network Security. Spring 2008 Lecture 24

Web basics: HTTP cookies

How is state managed in HTTP sessions. Web basics: HTTP cookies. Hidden fields (2) The principle. Disadvantage of this approach

Is Browsing Safe? Web Browser Security. Subverting the Browser. Browser Security Model. XSS / Script Injection. 1. XSS / Script Injection

Web basics: HTTP cookies

CSCD 303 Essential Computer Security Fall 2018

CSCD 303 Essential Computer Security Fall 2017

Web Security: Web Application Security [continued]

P2_L12 Web Security Page 1

CS 5450 HTTP. Vitaly Shmatikov

LECT 8 WEB SECURITY BROWSER SECURITY. Repetition Lect 7. WEB Security

Lecture 17 Browser Security. Stephen Checkoway University of Illinois at Chicago CS 487 Fall 2017 Some slides from Bailey's ECE 422

Web 2.0 and AJAX Security. OWASP Montgomery. August 21 st, 2007

2/16/18. CYSE 411/AIT 681 Secure Software Engineering. Secure Coding. The Web. Topic #11. Web Security. Instructor: Dr. Kun Sun

CSC 482/582: Computer Security. Cross-Site Security

Application vulnerabilities and defences

Web Security II. Slides from M. Hicks, University of Maryland

Web Security: XSS; Sessions

Web Security: Loose Ends

Web Application Security. Philippe Bogaerts

WEB SECURITY: XSS & CSRF

Advanced Web Technology 10) XSS, CSRF and SQL Injection

CSE 484 / CSE M 584: Computer Security and Privacy. Web Security. Autumn Tadayoshi (Yoshi) Kohno

CS 161 Computer Security

Application Layer Attacks. Application Layer Attacks. Application Layer. Application Layer. Internet Protocols. Application Layer.

Common Websites Security Issues. Ziv Perry

Lecture 9a: Sessions and Cookies

2/16/18. Secure Coding. CYSE 411/AIT 681 Secure Software Engineering. Web Security Outline. The Web. The Web, Basically.

WEB SECURITY WORKSHOP TEXSAW Presented by Solomon Boyd and Jiayang Wang

RKN 2015 Application Layer Short Summary

PROBLEMS IN PRACTICE: THE WEB MICHAEL ROITZSCH

Security for the Web. Thanks to Dave Levin for some slides

Security. CSC309 TA: Sukwon Oh

Robust Defenses for Cross-Site Request Forgery

Web Security: Vulnerabilities & Attacks

CS 142 Winter Session Management. Dan Boneh

Computer Security 3e. Dieter Gollmann. Chapter 18: 1

Security for the Web. Thanks to Dave Levin for some slides

Hacking Intranet Websites from the Outside

PROBLEMS IN PRACTICE: THE WEB MICHAEL ROITZSCH

Web Security IV: Cross-Site Attacks

Application Security through a Hacker s Eyes James Walden Northern Kentucky University

Cross-domain leakiness Divulging sensitive information & attacking SSL sessions Chris Evans - Google Billy Rios - Microsoft

CS 161 Computer Security

Web Application Security

CIS 4360 Secure Computer Systems XSS

Security and Privacy. SWE 432, Fall 2016 Design and Implementation of Software for the Web

Web Security: Web Application Security [continued]

Web Application Security

Web Security: Vulnerabilities & Attacks

Web Security Part 2. Professor Ristenpart h9p:// rist at cs dot wisc dot edu

Copyright

Excerpts of Web Application Security focusing on Data Validation. adapted for F.I.S.T. 2004, Frankfurt

CS 155 Project 2. Overview & Part A

OWASP Top 10 Risks. Many thanks to Dave Wichers & OWASP

CS 161 Computer Security

Browser code isolation

last time: command injection

CNIT 129S: Securing Web Applications. Ch 10: Attacking Back-End Components

Web Attacks, con t. CS 161: Computer Security. Prof. Vern Paxson. TAs: Devdatta Akhawe, Mobin Javed & Matthias Vallentin

INF3700 Informasjonsteknologi og samfunn. Application Security. Audun Jøsang University of Oslo Spring 2015

Presented By Rick Deacon DEFCON 15 August 3-5, 2007

GUI based and very easy to use, no security expertise required. Reporting in both HTML and RTF formats - Click here to view the sample report.

Web Application with AJAX. Kateb, Faris; Ahmed, Mohammed; Alzahrani, Omar. University of Colorado, Colorado Springs

Robust Defenses for Cross-Site Request Forgery

Attacks Against Websites. Tom Chothia Computer Security, Lecture 11

CS Paul Krzyzanowski

Computer Security. 14. Web Security. Paul Krzyzanowski. Rutgers University. Spring 2018

WebGoat Lab session overview

Client Side Injection on Web Applications


Lecture Notes on Safety and Information Flow on the Web: II

CSE361 Web Security. Attacks against the client-side of web applications. Nick Nikiforakis

XSS and CSRF Nov 6, 2018

Introduction to Ethical Hacking

Web Application Security

Attacks Against Websites 3 The OWASP Top 10. Tom Chothia Computer Security, Lecture 14

Web Security, Part 2

The security of Mozilla Firefox s Extensions. Kristjan Krips

More attacks on clients: Click-jacking/UI redressing, CSRF

Web Attacks CMSC 414. September 25 & 27, 2017

Chrome Extension Security Architecture

5/19/2015. Objectives. JavaScript, Sixth Edition. Saving State Information with Query Strings. Understanding State Information

CSE 127 Computer Security

Some Facts Web 2.0/Ajax Security

CNIT 129S: Securing Web Applications. Ch 3: Web Application Technologies

Project 2: Web Security

Application Security Introduction. Tara Gu IBM Product Security Incident Response Team

Assignment 6: Web Security

Web Security. Jace Baker, Nick Ramos, Hugo Espiritu, Andrew Le


s642 web security computer security adam everspaugh

Security Course. WebGoat Lab sessions

Web Security Part 2. Professor Ristenpart h9p:// rist at cs dot wisc dot edu

Transcription:

Cristina Nita-Rotaru CS526: Information security

Readings for This Lecture Wikipedia } HTTP Cookie } Same Origin Policy } Cross Site Scripting } Cross Site Request Forgery 2

1: Background

Background } Many sensitive tasks are done through web } Online banking, online shopping } Database access } System administration } Web applications and web users are targets of many attacks } Cross site scripting } SQL injection } Cross site request forgery } Information leakage } Session hijacking 4

Browser and Network Browser OS Hardware request reply Network Web site } Browser sends requests } May reveal private information (in forms, cookies) } Browser receives information, code } May corrupt state by running unsafe code } Interaction susceptible to network attacks } Use HTTPS, which uses SSL/TLS 5

Web Security Issues } Secure communications between client & server } HTTPS (HTTP over Secure Socket Layer) } User authentication & session management } Cookies & other methods } Active contents from different websites } Protecting resources maintained by browsers } Web application security } Web site authentication (e.g., anti-phishing) } Privacy concerns 6

HTTP: HyperText Transfer Protocol } Browser sends HTTP requests to the server } Methods: GET, POST, HEAD, } GET: to retrieve a resource (html, image, script, css, ) } POST: to submit a form (login, register, ) } HEAD } Server replies with a HTTP response } Stateless request/response protocol } Each request is independent of previous requests } Statelessness has a significant impact on design and implementation of applications 7

HTTP } HTTP is a stateless protocol. } Hosts do not need to retain information about users between requests } Web applications must use alternative methods to track the user's progress from page to page } sending and receiving cookies } server side sessions, hidden variables and URL encoded parameters (such as /index.php? session_id=some_unique_session_code). 8

Use Cookies to Store State Info } Cookies } A cookie is a name/value pair created by a website to store information on your computer Browser Enters form data Response + cookies Server Browser Request + cookies Returns data Server Http is stateless protocol; cookies add state 9

Cookies Fields } An example cookie from my browser } Name session-token } Content "s7yziovfm4yymg. } Domain.amazon.com } Path / } Send For Any type of connection } Expires Monday, September 08, 2031 7:19:41 PM 10

More about Cookies } Stored by the browser } Used by the web applications } used for authenticating, tracking, and maintaining specific information about users } e.g., site preferences, contents of shopping carts } Cookie ownership } Once a cookie is saved on your computer, only the website that created the cookie can read it } Security aspects } Data may be sensitive } May be used to gather information about specific users 11

Web Authentication via Cookies } HTTP is stateless } How does the server recognize a user who has signed in? } 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 (session id) } With each request, browser presents the cookie } Server verifies the authenticator 12

A Typical Session with Cookies client server POST /login.cgi Set-Cookie:authenticator GET /restricted.html Cookie:authenticator Restricted content Verify that this client is authorized Check validity of authenticator Authenticators must be unforgeable and tamper-proof (malicious clients shouldn t be able to modify an existing authenticator) 13

Browser Cookie Management } Cookie Same-origin ownership } Once a cookie is saved on your computer, only the Web site 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 a web site other than the one that provided the current page 14

Example: Third-Party Cookies } Get a page from merchant.com } Contains <img src=http://doubleclick.com/advt.gif> } Image fetched from DoubleClick.com } DoubleClick knows IP address and page you were looking at } DoubleClick sends back a suitable advertisement } Stores a cookie that identifies "you" at DoubleClick } Next time you get page with a doubleclick.com image } Your DoubleClick cookie is sent back to DoubleClick } DoubleClick could maintain the set of sites you viewed } Send back targeted advertising (and a new cookie) } Cooperating sites } Can pass information to DoubleClick in URL, 15

Example: Session State in URL www.e_buy.com www.e_buy.com/ shopping.cfm? pid=269& item1=102030405 View Catalog Select Item Check out www.e_buy.com/ shopping.cfm? pid=269 www.e_buy.com/ checkout.cfm? pid=269& item1=102030405 Store session information in URL; Easily read on network 16

2: Cross Site Scripting

Client Side Scripting } Web pages (HTML) can embed dynamic contents (code) that can be executed on the browser } JavaScript } embedded in web pages and executed inside browser } Java applets } small pieces of Java bytecodes that execute in browsers 18

HTML and Scripting <html> Browser receives content, displays <P> HTML and executes scripts <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> 19

Scripts are Powerful } Client-side scripting is powerful and flexible, and can access the following resources } Local files on the client-side host } read / write local files } Webpage resources maintained by the browser } Cookies } Domain Object Model (DOM) objects steal private information control what users see impersonate the user 20

Browser as an Operating System } Web users visit multiple websites simultaneously } A browser serves web pages (which may contain programs) from different web domains } a browser runs programs provided by mutually untrusted entities } running code one does not know/trust is dangerous } a browser also maintains resources created/updated by web domains } Browser must confine (sandbox) these scripts so that they cannot access arbitrary local resources } Browser must have a security policy to manage/protect browser-maintained resources and to provide separation 21 among mutually untrusted scripts

Same Origin Policy } The basic security model enforced in the browser } SoP isolates the scripts and resources downloaded from different origins } E.g., evil.org scripts cannot access bank.com resources } Use origin as the security principal } Origin = domain name + protocol + port } all three must be equal for origin to be considered the same 22

Same Original Policy: What it Controls } Same-origin policy applies to the following accesses: } manipulating browser windows } URLs requested via the XmlHttpRequest } XmlHttpRequest is an API that can be used by web browser scripting languages to transfer XML and other text data to and from a web server using HTTP, by establishing an independent and asynchronous communication channel. used by AJAX } manipulating frames (including inline frames) } manipulating documents (included using the object tag) } manipulating cookies 23

Problems with S-O Policy } Poorly enforced on some browsers } Particularly older browsers } Limitations if site hosts unrelated pages } Example: Web server often hosts sites for unrelated parties } http://www.example.com/account/ } http://www.example.com/otheraccount/ } Same-origin policy allows script on one page to access properties of document from another } Can be bypassed in Cross-Site-Scripting attacks } Usability: Sometimes prevents desirable cross-origin resource sharing 24

Cross Site Scripting (XSS) } Recall the basics } scripts embedded in web pages run in browsers } scripts can access cookies } get private information } and manipulate DOM objects } controls what users see } scripts controlled by the same-origin policy } Why would XSS occur } Web applications often take user inputs and use them as part of webpage (these inputs can have scripts) 25

How XSS Works on Online Blog } Everyone can post comments, which will be displayed to everyone who views the post } Attacker posts a malicious comment that includes script (which reads local authentication credentials and sends them of to the attacker) } Anyone who viewed the post can have local authentication cookies stolen } Web apps will check that posts do not include scripts, but the check sometimes fail. } Bug in the web application. Attack happens in browser. 26

Effect of the Attack } Attacker can execute arbitrary scripts in browser } Can manipulate any DOM component on victim.com } Control links on page } Control form fields (e.g. password field) on this page and linked pages. } Can infect other users: MySpace.com worm. 27

MySpace.com (Samy worm) } Users can post HTML on their pages } MySpace.com ensures HTML contains no <script>, <body>, onclick, <a href=javascript://> } However, attacker find out that a way to include Javascript within CSS tags: <div style= background:url( javascript:alert(1) ) > And can hide javascript as java\nscript } With careful javascript hacking: } Samy s worm: infects anyone who visits an infected MySpace page and adds Samy as a friend. } Samy had millions of friends within 24 hours. } More info: http://namb.la/popular/tech.html 28

Avoiding XSS bugs (PHP) } Main problem: } Input checking is difficult --- many ways to inject scripts into HTML. } Preprocess input from user before echoing it } PHP: htmlspecialchars(string) & & " " ' &#039; < < > > } htmlspecialchars( "<a href='test'>test</a>", ENT_QUOTES); Outputs: <a href=&#039;test&#039;>test</a> 29

Avoiding XSS bugs (ASP.NET) } ASP.NET 1.1: } Server.HtmlEncode(string) } Similar to PHP htmlspecialchars } validaterequest: (on by default) } Crashes page if finds <script> in POST data. } Looks for hardcoded list of patterns. } Can be disabled: <%@ Page validaterequest= false" %> 30

3: Cross site request forgery

Cross site request forgery (abbrev. CSRF or XSRF) } Also known as one click attack or session riding } Effect: Transmits unauthorized commands from a user who has logged in to a website to the website. } Recall that a browser attaches cookies set by domain X to a request sent to domain X; the request may be from another domain } Site Y redirects you to facebook; if you already logged in, the cookie is attached by the browser 32

CSRF Explained } Example: } User logs in to bank.com. Forgets to sign off. } Session cookie remains in browser state } Then user visits another site containing: <form name=f action=http://bank.com/billpay.php> <input name=recipient value=badguy> <script> document.f.submit(); </script> } Browser sends user auth cookie with request } Transaction will be fulfilled } Problem: } The browser is a confused deputy; it is serving both the websites and the user and gets confused who initiated a request 33

GMail Incidence: Jan 2007 } Allows the attacker to steal a user s contact } Google docs has a script that run a callback function, passing it your contact list as an object. The script presumably checks a cookie to ensure you are logged into a Google account before handing over the list. } Unfortunately, it doesn t check what page is making the request. So, if you are logged in on window 1, window 2 (an evil site) can make the function call and get the contact list as an object. Since you are logged in somewhere, your cookie is valid and the request goes through. 34

Real World CSRF Vulnerabilities } Gmail } NY Times } ING Direct (4th largest saving bank in US) } YouTube } Various DSL Routers } Purdue WebMail } PEFCU } Purdue CS Portal } 35

Prevention } Server side: } use cookie + hidden fields to authenticate a web form } hidden fields values need to be unpredictable and user-specific; thus someone forging the request need to guess the hidden field values } requires the body of the POST request to contain cookies } Since browser does not add the cookies automatically, malicious script needs to add the cookies, but they do not have access because of Same Origin Policy } User side: } logging off one site before using others } selective sending of authentication tokens with requests (may cause some disruption in using websites) 36

Other Web Threats } SQL Injection } Side channel leakages } Web browsing privacy: third-party cookies 37

3: SQL-injection

39 Acknowledgments: xkcd.com

What is a SQL Injection Attack? } Many web applications take user input from a form } Often this user input is used literally in the construction of a SQL query submitted to a database. } SELECT productdata FROM table WHERE productname = user input product name ; } A SQL injection attack involves placing SQL statements in the user input 40

An Example SQL Injection Attack } Product Search: blah OR x = x } This input is put directly into the SQL statement within the Web application: } $query = SELECT prodinfo FROM prodtable WHERE prodname =. $_POST[ prod_search ]. ; } Creates the following SQL: } SELECT prodinfo FROM prodtable WHERE prodname = blah OR x = x } Attacker has now successfully caused the entire database to be returned. 41

SQL Injection Attacks Results } Add new data to the database } Modify data currently in the database } Could be very costly to have an expensive item suddenly be deeply discounted } Often can gain access to other user s system capabilities by obtaining their password 42

Defenses } Use provided functions for escaping strings } Many attacks can be thwarted by simply using the SQL string escaping mechanism à \ and à \ } Check syntax of input for validity } Many classes of input have fixed languages } Have length limits on input } Many SQL injection attacks depend on entering long strings } Scan query string for undesirable word combinations that indicate SQL statements } Limit database permissions and segregate users } Connect with read-only permission if read is the goal } Don t connect as a database administrator from web app 43

Defenses: PREPARE statement } For existing applications adding PREPARE statements will prevent SQL injection attacks } Hard to do automatically with static techniques } Need to guess the structure of query at each query issue location } Query issued at a location depends on path taken in program } Human assisted efforts can add PREPARE statements } Costly effort } Is it possible to dynamically infer the benign query structure? 44

Dynamic Candidate Evaluations } Create benign sample inputs (Candidate Inputs) for every user input } Execute the program simultaneously over actual inputs and candidate inputs } Generate a candidate query along with the actual query } The candidate query is always non-attacking } Actual query is possibly malicious } Issue the actual query only if parse structures match 45

Finding Benign Candidate Inputs } Have to create a set of candidate inputs which } } } Are Benign Issue a query at the same query issue location By following the same path in the program Candidate Path Actual Path Problem in the most general case it is undecidable Query Issue Location 46

Use Manifestly Benign Inputs Phonebook Record Manager User Name John Password 47 os Display Submit Delete } For every string create a sample string of a s having the same length } Candidate Input: uname = aaaa pwd = aa } Shadow every intermediate string variable that depends on input } For integer or boolean variable, use the originals } Follow the original control flow

Candidate Input : uname = aaaa pwd = aa display = true input str uname, str pwd, bool display User Input : Candidate uname = john Input : pwd = os uname = aaaa display = false pwd = aa true display? false query = SELECT * from phonebook WHERE username = + uname + AND password = + pwd + query = DELETE * from phonebook WHERE username = + uname + AND password = + pwd + tual Query: DELETE * from phonebook WHERE username = john AND password = os andidate Query: DELETE * from phonebook WHERE username = aaaa AND password = aa 48

Program Transformation Example i/p str uname; i/p str pwd; i/p bool delete; str uname_c; str pwd_c; uname = input_1, pwd = input_2, delete = input_3; uname_c = createsample(uname), pwd_c = createsample(pwd); false display? true query = DELETE * from phonebook WHERE username = + uname + AND password = + pwd + query_c = DELETE * from phonebook WHERE username = + uname_c + AND password = + pwd_c + ; query = SELECT * from phonebook WHERE username = + uname + AND password = + pwd + ; query_c = SELECT * from phonebook WHERE username = + uname_c + AND password = + pwd_c + ; 49 if(match_queries(query,query_c) execute_query(query) == true) execute_query(query)

CANDID Implementation Architecture n Offline View Original Program Java Bytecode transformer java bytecode Instrumented Web Application n Online View Web Server Tomcat server Browser SQL Parse Tree Checker java Instrumented Web Application DB MySql 50 java bytecode

Readings for This Lecture Optional Reading } Bandhakavi et al.: CANDID : Preventing SQL Injection Attacks Using Dynamic Candidate Evaluations } Chen et al.: Side-Channel Leaks in Web Applications: a Reality Today, a Challenge Tomorrow 51

Browser Cookie Management } Cookie Same-origin ownership } Once a cookie is saved on your computer, only the Web site 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 a web site other than the one that provided the current page 52

Third-party cookies } Get a page from merchant.com } Contains <img src=http://doubleclick.com/advt.gif> } Image fetched from DoubleClick.com } DoubleClick knows IP address and page you were looking at } DoubleClick sends back a suitable advertisement } Stores a cookie that identifies "you" at DoubleClick } Next time you get page with a doubleclick.com image } Your DoubleClick cookie is sent back to DoubleClick } DoubleClick could maintain the set of sites you viewed } Send back targeted advertising (and a new cookie) } Cooperating sites } Can pass information to DoubleClick in URL, 53

Cookie issues } Cookies maintain record of your browsing habits } Cookie stores information as set of name/value pairs } May include any information a web site knows about you } Sites track your activity from multiple visits to site } Sites can share this information (e.g., DoubleClick) } Browser attacks could invade your privacy 54