Web Application Security. Recap: System Security Prof. Dr. Michael Backes. CISPA Center for IT Security, Privacy and Accountabiltiy

Size: px

Start display at page:

Download "Web Application Security. Recap: System Security Prof. Dr. Michael Backes. CISPA Center for IT Security, Privacy and Accountabiltiy"

Rosaline Neal
5 years ago
Views:

1 Web Application Security Prof. Dr. Michael Backes Director, CISPA Center for IT Security, Privacy, and Accountability Chair for IT-security & Cryptography Recap: System Security Prof. Dr. Michael Backes Chapter System Security Overview Practical security (How to exploit vulnerabilities?) - Security principles - Basic design of (in-)secure systems - Basics of access control, malware - How to hijack control in computer systems? - How to defend against such control hijacking attacks? - Authentication methods Project: Learn about basic control-flow hijacking 2 1

Recap: Common Types of Control Flow Attacks Assumptions are vulnerabilities Discover which assumptions are made Craft exploit outside assumptions Hijacked Two assumptions often

violate this assumption Recap: Buffer Overflow Why is an assumption about data length dangerous?

.. Variables: Colour Nav Email Price Red Yes backes@mpi-sws.

2 Recap: Common Types of Control Flow Attacks Assumptions are vulnerabilities Discover which assumptions are made Craft exploit outside assumptions Hijacked Two assumptions often exploited: - Target buffer is large enough for source data Buffer overflows deliberately break this assumption - Computer integers behave like math integers Integer overflows violate this assumption Recap: Buffer Overflow Why is an assumption about data length dangerous? Computer programs organise internal data values in variables stored in memory Reserved 50 characters for PC Memory Program Car configurator Another program... Variables: Colour Nav Price Red Yes backes@mpi-sws.org looooooooooooooooooong Recap: Buffer Overflow and Changing Variable Values The car configurator example allows us to overwrite the associated price using a very long address 51 characters looooooooooooo...oooooong 7 [ l ][ o ][ ][ o ][ n ][ g ][ m ][ a ][ i][ l] Car for 7 Memory for variable (size: 50 characters) Memory for price variable 2

Recap: Control Flow Hijacking Attack What

return address to the stack that we have

3 Recap: Control Flow Hijacking Attack What can we do with an overwritten return address? Everything! Call an arbitrary address in memory Call arbitrary functions or only parts of functions Call our own code by pointing the return address to the stack that we have overwritten Web Application Security Prof. Dr. Michael Backes What are web applications? 13 3

Client-Server communication 1 User request webpage with dynamic content 2 Web application queries database 1 2 4 3

com 3 DB data is used by application to generate page content 4 Received data is rendered by the client s browser 14

Unencrypted Hypertext Transfer Protocol Secure (HTTPS) Port 443 Encrypted by SSL/TLS 15 Uniform Resource Locator (URL)

4 Client-Server communication 1 User request webpage with dynamic content 2 Web application queries database Source: algomatik.com 3 DB data is used by application to generate page content 4 Received data is rendered by the client s browser 14 Communication Protocol Hypertext Transfer Protocol (HTTP) Widely used application-layer protocol Simple Port 80 Stateless Unencrypted Hypertext Transfer Protocol Secure (HTTPS) Port 443 Encrypted by SSL/TLS 15 Uniform Resource Locator (URL) Global identifiers of network-retrievable documents HTTP Example: Port Query Protocol Hostname Path Fragment Characters with special meaning are encoded as hex (URL-encoding) 16 4

5 HTTP request Method File HTTP version Headers GET /index.html HTTP/1.1 Accept: image/gif, image/x-bitmap, image/jpeg, */* Accept-Language: en Connection: Keep-Alive User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/ (KHTML, like Gecko) Chrome/ Safari/ Host: Referer: mandatory blank line Data none for GET GET no side effects POST possible side effects 17 HTTP response HTTP version Status code Reason phrase Headers HTTP/ OK Date: Tue, 25 Nov :47:05 GMT Server: Apache/ (CentOS) Connection: keep-alive Content-Type: text/html Last-Modified: Thu, 13 Oct :39:05 GMT Etag: "e bb5a49f331" Set-Cookie: Content-Length: 2543 <HTML> actual website content.. </HTML> Cookies Data 18 Web application security problems What is the problem? Delusive simplicity for creating web apps Lack of security awareness Time- & resource limits during development Rapid increase in code complexity Company's security focus shifts towards web Security perimeter moves from network to application layer Web applications intentionally expose functionality to the Internet while being connected to internal servers (e.g. database servers) Controlling network traffic via port blocking is no longer effective on application layer (port 80/443 problem) 19 5

com Client-side attacks such as Cross-site scripting (XSS) Cross-site

6 Port 80/443 Problem Source: SecureNet GmbH 20 Common web attacks Source: algomatik.com Client-side attacks such as Cross-site scripting (XSS) Cross-site request forgery (CSRF) Server-side attacks such as SQL injection Path traversal Remote Code Injection 21 Purposes of web attacks Source: cloudbric.com 23 6

7 Common vulnerabilities (II) 24 Server-side attacks SQL injection SQL Introduction What is SQL? SQL: Structured Query Language Widely used database query language Syntax (mostly) independent of vendor Application (web, mobile, ) StudentID Name Pwd Semester Schmidt 3DxEE00 2 Students CourseID CourseName Semester SQL Queries Cyber Security WS14 Courses Data Base (DB) 26 7

8 SQL Introduction Some basic SQL syntax Fetch a set of records SELECT * FROM <table_name> WHERE CONDITIONS; Insert record into table INSERT INTO <table_name> (column1, column2, ) VALUES (value1,value2, ); Delete table DROP TABLE <table_name>; StudentID Name Pwd Semester Schmidt 3DxEE Meyer 3DxEA11 3 CourseID students CourseName Semester Cyber Security WS14 courses DB Examples: SELECT * FROM students WHERE Semester = 2 ; StudentID Name Pwd Semester Schmidt 3DxEE00 2 INSERT INTO courses (CourseName, Semester) VALUES (Android Security Lab, WS14); CourseID CourseName Semester Cyber Security WS Android Security Lab WS14 27 Server-side attacks - SQL injection What is SQL injection? Input Validation Vulnerability Untrusted user input in SQL query sent to backend database without sanitizing the data Why is this bad? Data can be misinterpreted as a command Source: danieldafoe.com Can alter the intended effect of command or query 28 Interlude: PHP - Hypertext Preprocessor Server scripting language with C-like syntax Can intermingle static HTML and code <input value=<?php echo $myvalue;?>> Can embed variables in double-quote strings $user = "world"; echo "Hello $user!"; or $user = "world"; echo "Hello". $user. "!"; Form data in global arrays $_GET, $_POST,

9 SQL injection example wget $user = $_GET["username"]; $pass = $_GET["password"]; $sql = "SELECT * FROM UserTable WHERE User = '" + $user + "' AND Passwd = '" + $pass + "'"; 30 SQL injection example wget $user = "admin"; $pass = "' OR '1'='1"; $sql = "SELECT * FROM UserTable WHERE User = 'admin' AND Passwd = '' OR '1'='1'"; WHERE clause rewritten according to operator precedence: $sql = "SELECT * FROM UserTable WHERE (User = 'admin' AND Passwd = '') OR '1'='1'"; '1'= '1' evaluates to TRUE all user data is leaked 31 SQL injection example (II) wget $user = "admin'--"; $pass = ""; $sql = "SELECT * FROM UserTable WHERE User = 'admin'--' AND Passwd = ''"; Double-dash starts a comment until end of the line $sql = "SELECT * FROM UserTable WHERE User = 'admin'--' AND Passwd = ''"; WHERE clause skips password check and retrieves admin record 32 9

10 SQL injection example (III) Source: hackaday.com 33 SQL injection What is the problem? Insufficient validation of untrusted data Never trust user input! Validate input data according to specified requirements e.g.: only dots and numbers in birthdays Consequences Information leakage: '; SELECT * FROM Data manipulation: '; INSERT INTO Sabotage: '; DROP TABLE users SQL injection Exploits of a Mom Source: xkcd.com/

11 Preventing SQL injection Input validation Filter Apostrophes, semicolons, percent symbols, hyphens, underscores,.. Any character that has special meaning Check the data type (e.g. make sure it s an integer) Whitelisting Blacklisting chars doesn t work Forget to filter out some characters Could prevent valid input (e.g. username O Brien) Allow only well-defined set of safe values Set implicitly defined through regular expressions 36 Prepared statements Metacharacters (e.g. ) in queries provide distinction between data & control Most attacks: data interpreted as control / alters the semantics of a query/cmd Bind variables:? Placeholders guaranteed to be data (not control) bind variables are typed, e.g. int, string,.. Prepared statements allow creation of static queries with bind variables Preserves the structure of intended query $stmt = $dbh->prepare( "SELECT * FROM UserTbl WHERE User =? AND Passwd =?"); $stmt->execute(array($username, $pass)); 37 Client-side attacks Cross-site scripting (XSS) 38 11

39 Same origin policy Externally loaded content might be malicious or not Steal credentials Track the user,.

12 Same origin policy The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating external code (e.g. via iframes) Two pages have the same origin if the tuple <protocol, port (if specified), host> are the same for both pages. 39 Same origin policy Externally loaded content might be malicious or not Steal credentials Track the user,.. Origin of content not always obvious 40 Same origin policy domains on example web page Do you know if these domains are trustworthy? 41 12

13 Is it the same origin? Reference URL: URL Result Reason Success Same protocol, host, and port Failure Different protocol Success Same protocol,host, and port Failure Different host (exact match required) Failure Different port Success Same protocol,host, and port 43 Session Management Session: A sequence of requests and responses from one browser to one (or more) sites Why sessions? HTTP is stateless No continuing user state Users would have to constantly re-authenticate Web applications have to implement their own session tracking mechanism Sessions can be long (Google multiple weeks) or short (Online Banking) An authenticated user gets assigned a session identifier (SID) Every request containing this SID is regarded to belong to this user 44 Web session management: Common methods URL rewriting The SID is included in every URL that points to a resource of the web application <a href="checkout.htm?sid=kh7y3b"> </a> Problem: SID leakage via referrer or HTTP proxy logs Form-based session-id Forms are used for navigation through the app HTML rather than hyperlinks SID is stored in hidden form field that is transmitted whenever a navigation on this form is initiated: <input type="hidden" name="sessionid" value="kh7y3b"> Problems: not-usable if user connects from another window the Back-button of the browser 45 13

Web session management: Cookies Small text information Send from server to webbrowser or Generated via scripts (e.g. JavaScript) Identified via 3-Tuple (name, domain, path) Cookie Header: Set-Cookie: $NAME = $VALUE (; $ATTRIBUTE) Cookie: $NAME = $VALUE (; $NAME = VALUE.

14 Web session management: Cookies Small text information Send from server to webbrowser or Generated via scripts (e.g. JavaScript) Identified via 3-Tuple (name, domain, path) Cookie Header: Set-Cookie: $NAME = $VALUE (; $ATTRIBUTE) Cookie: $NAME = $VALUE (; $NAME = VALUE..) Special Attributes: secure: cookie is only sent via HTTPS HttpOnly: cookie cannot be accessed via script Source: comicvine.com 46 Web session management: Cookies The server sets a cookie at the client's browser after the authentication form The client's requests are treated as authorized as long as this cookie is valid 47 Web session management: Cookies Cookie scope Session ID Expires 48 14

15 Session Hijacking A malicious script obtains the SID All presented SID mechanisms (URL, Form, Cookie) are vulnerable SID is transmitted to attacker Attacker implants cookie into own browser This attack can be prevented with HttpOnly Cookies (cookies that cannot be accessed by scripts) Source: quickmeme.com 49 Cookies: Powering the modern web 50 Cookies: Prime target for attacks 51 15

Social Engineering: Stealing Cookies Source: http://thehackernews.

html 52 Social Engineering: Stealing Cookies What do you think was the impact of this

vulnerability is present when an attacker can inject scripting code into pages generated

Cross-site scripting variants: Reflective XSS The attack script is reflected back to the

16 Social Engineering: Stealing Cookies Source: 52 Social Engineering: Stealing Cookies What do you think was the impact of this scam? 53 Client-side attacks Cross-site scripting A cross-site scripting (XSS) vulnerability is present when an attacker can inject scripting code into pages generated by a web application The attack is mounted if users can be tricked to access these pages Cross-site scripting variants: Reflective XSS The attack script is reflected back to the user as part of a page from the victim site Stored XSS The attacker stores the malicious code in a resource managed by the web app such as a database 54 16

Recent XSS vulnerabilities XSS affects almost

ru - Stanford - UPS - and many more by xssed.

/ site defacement 56 XSS consequences (cont d)

of login dialogues Phishing of username /

17 Recent XSS vulnerabilities XSS affects almost any larger website - Samsung - Mail.ru - Stanford - UPS - and many more by xssed.com 55 XSS consequences Web content alteration / site defacement 56 XSS consequences (cont d) Web content alteration Site defacement Spoofing of login dialogues Phishing of username / password Site redirection / phishing Session hijacking Steal session identifier to impersonate victim user Browser hijacking Launch attacks against third parties 57 17

Interlude: JavaScript JavaScript Introduced by Netscape in 1995 Implemented in every modern web browser Capabilities Interaction with the user Document content alteration Controlling the browser,

18 Interlude: JavaScript JavaScript Introduced by Netscape in 1995 Implemented in every modern web browser Capabilities Interaction with the user Document content alteration Controlling the browser, accessing the cookies Asynchronous communication JavaScript is pretty much almighty.. 58 Basic XSS Tag Injection Hello <b><script>..</script></b>! Breaking out ofhtml attributes (callbacks) <img src="foo.jpg" onload="<script>.."/> JavaScript URLs <img src="javascript:.."/> Many more examples: XSS Cheat Sheet: owasp.org/index.php/xss_filter_evasion_cheat_sheet 59 Reflected XSS 1 Attack Server 2 5 Victim client Victim Server 60 18

19 Reflected XSS Attack Server 5 Victim client Send bad stuff Reflect it back Victim Server 61 Reflected XSS Is found if a web application blindly echos user provided data Typical examples Search forms/bars Custom error pages (e.g. username John does not exist ) For exploitation, the attacker has to lure the victim to access vulnerable page via a link that includes a malicious script: 62 Reflected XSS - Search Try it at google.com/about/appsecurity/learning/xss 63 19

20 Stored XSS The web application permanently stores user-provided data In its database via input fields or guest books This data is subsequently used to generate website content Every time the vulnerable web page is visited the malicious code is executed at the victim s browser 64 Stored XSS Attack Server Victim client 1 Inject Store bad malicious stuff script Download it Victim Server 65 Stored XSS - Guestbook 66 20

21 Myspace.com (Samy Worm ) Users can post HTML on their pages MySpace.com ensures HTML contains no <script>, <body>, onclick, <a href=javascript://> but can do Javascript within CSS tags: <div style= background:url( javascript:alert(1) ) > And can hide javascript as java\nscript With careful javascript hacking: Samy worm infects anyone who visits an infected MySpace page and adds Samy as a friend. Samy had millions of friends within 24 hours. 67 Avoiding XSS Rule of thumb: Never ever trust user-provided data! Apply rigorous inputvalidation Non-trivial: consider various kinds of input encodings! Use whitelist checking instead of blacklist filtering Apply output filtering Remove script code from all locations which are not explicitly specified by the developer Use Content Security Policy (CSP) 68 Content Security Policy Content Security Policy (CSP) prevents XSS, clickjacking and other code injection attacks resulting from execution of malicious scripts in the trusted website context Implemented as HTTP response header Content-Security-Policy Allows to specify a whitelist of dynamic sources that are allowed to be loaded Disallows inline scripts, HTML event handlers (onclick) and javascript: urls Restrictive default policy Enforced split between markup and logic Enforcement and reporting modes Supported by all major browsers (but: only limited support of IE) Example: Allow Scripts only from Same origin, Google Analytics and Google AJAX CDN script-src 'self' ajax.googleapis.com; 69 21

22 Browser Development 70 Browser Development In older days new major browser releases could take years New features were introduced not very frequently Still, security updates were released promptly Release dates of older versions of Mozilla Firefox Version Release date Firefox 2.0 October 2006 Firefox 3.0 June 2008 Firefox 3.5 June 2009 Firefox 4.0 March 2011 Downsides of this development model include Users rarely get new features, only security updates Non-agile development process 71 Browser Development Browsers like Chrome and Firefox switched to rolling release model Releases take place at regular intervals, e.g. every six weeks Features that are not ready are scheduled for next release Goal is to provide regular improvements to users Development takes place in different channels Usually 4-5 channels Evolving code is copied to next (more stable) channel Last channel usually called release channel 72 22

Firefox Development Channel mozilla-central (nightly) New features as soon as they are ready Unstable, UI might change daily mozilla-aurora (experimental) Stabilize work done on nightly, disable

development in central Other channels devoted for stabilizing features Roughly any six weeks code is copied to the next channel With each channel the user base roughly grows by factor 10 Security

23 Firefox Development Channel mozilla-central (nightly) New features as soon as they are ready Unstable, UI might change daily mozilla-aurora (experimental) Stabilize work done on nightly, disable features that are not ready mozilla-beta Receives only new features slated for next release Bug fixing mozilla-release (stable) Official release unstable stable 73 Firefox Release Schedule Continuous development in central Other channels devoted for stabilizing features Roughly any six weeks code is copied to the next channel With each channel the user base roughly grows by factor 10 Security fixes are an exception and released faster 74 What about security vulnerabilities? Why browsers are vulnerable: Chrome has over 5 million lines of code Firefox has over 12 million lines of code Flaws anywhere in design/implementation can lead to exploit But that s not all: what about third-party browser plugin s? Chrome Security Vulnerabilities: Source: cvedetails.com 75 23

Measuring severity of a vulnerability Security vulnerabilities must be fixed as soon as possible Problem: On average a vulnerability is reported every second day!

unpatched Harm Damage if attack works 76 Measuring severity of a vulnerability Many vulnerabilities are reported to CVE (Common Vulnerabilities and exposures) database

24 Measuring severity of a vulnerability Security vulnerabilities must be fixed as soon as possible Problem: On average a vulnerability is reported every second day! Limited number of developers Goal: Measure severity of vulnerabilities and prioritize fixing Frequency of interactions with attacker Percentage of time vulnerability is unpatched Harm Damage if attack works 76 Measuring severity of a vulnerability Many vulnerabilities are reported to CVE (Common Vulnerabilities and exposures) database publicly available at: CVE vulnerability score reflects severity Good news: In 2014, 83% of vulnerabilities had patches ready before flaws became public! 77 24

Information Security CS 526 Topic 11

Information Security CS 526 Topic 11 Web Security Part 1 1 Readings for This Lecture Wikipedia HTTP Cookie Same Origin Policy Cross Site Scripting Cross Site Request Forgery 2 Background Many sensitive