NISNet Winter School Finse 2008 1 Internet & Web Security Case Study 3: Web application security Dieter Gollmann Hamburg University of Technology [email protected]

1

NISNet Winter School Finse 2008

Internet & Web SecurityCase Study 3: Web application security

Dieter Gollmann

Hamburg University of Technology

[email protected]

2


Web Security – Introduction Web designed to share scientific documents;

originally little concern for security.

Many components involved: Servers (Apache, IIS, etc.) Applications (written in Java, C, Perl, etc.) Browsers (IE, Netscape, etc.) Protocols, languages, data formats (HTTP, XML, SQL, SSL) Operating systems (Windows, Linux, Unix, Mac OS)

Application level vulnerabilities account today for an increasing number of security problems. Cross site scripting (XSS) first in 2005 CVE list and in the

2007 OWASP Top Ten vulnerabilities.

3


Introduction

Web applications typically accept inputs from remote sites.

Web applications may use addresses (IP addresses, DNS names) as the basis for authorisation decisions.

Web applications may establish common state between participants and refer to this common state when authorising requests.

All these points can become vulnerabilities.

4


Agenda

Web processing model (simplified)

Sessions

Same Origin Policy

Cross-site scripting

Cross-site request forgery

JavaScript hijacking

DNS Rebinding attack

5


Web processing model

6


Web processing model

web server

backend systems

browser

HTTPrequest

HTML +CSS data

client

server

7


Web applications – infrastructure

Logic of a web application implemented at web server and back-end server. Web server known by its domain name.

Transport protocol specifies data formats and encoding & decoding of application payloads. Transport: HTTP; data format: HTML (and

Cascading Style Sheets (CSS)).

Processing at client side managed by browser. Client has no name other than its IP address.

8


Web applications – processing

Client sends HTTP request to web server. Client’s browser has to resolve server’s domain name to an

IP address.

Script at web server extracts input from client request; constructs a request to backend application server.

Web server gets result from backend server, returns a HTML result page to client.

Client’s browser displays result page.

DOM (Domain Object Model) internal representation of HTML page.

9


Sessions HTTP is stateless; Web applications can create

sessions on top of HTTP or use SSL sessions established in the network layer.

To create a session on top of HTTP, the server generates a session identifier and sends it to client.

Client includes session identifier in subsequent requests to server.

Requests are authenticated as belonging to a session if they contain the correct session identifier.

Sessions could be established for a particular user.

10


Creating HTTP sessions Cookies: Sent by server in an HTTP response using

the Set-Cookie header field; the client’s browser stores it in document.cookie and includes it in all requests with a domain matching the cookie’s origin.

URL query strings: SID (session identifier as defined in HTTP) included in every URL that points to a resource of the web application.

POST parameters: SID stored in a hidden field in an HTML form.

Cookie contains common state; SID is a reference to common state maintained at server.

11


New Threat Model Cookie poisoning: Outside attacker or malicious client

spoofs or changes common state by forging cookie.

The attacker can be a malicious end system.

Attacker only sees messages addressed to him and data obtained from compromised end systems.

The attacker can guess predictable fields in unseen messages.

Imposes two requirements on session identifiers: must be unpredictabile and stored in a safe place.

This is not the ‘old’ secret services threat model!

12


Same Origin Policy

13


Same Origin Policy (SOP) Enforced by web browsers to protect application

payloads and session identifiers from third parties.

Web application identified by domain of its hosting web server.

An applet may only connect back to the domain it came from.

A cookie is only included in requests to the domain that had placed it.

Two pages “have the same origin” if they share protocol, host name and port number.

14


SOP for http://www.my.org/dir1/hello.html

URL Result Reason

http://www.my.org/dir1/other.html success

http://www.my.org/dir2/sub/other.html success

https://www.my.org/dir2/some.html failure protocol

http://www.my.org:81/dir2/some.html failure port

http://host.my.org/dir2/some.html failure host

15


Relaxing the Same Origin Policy

If you do not want to distinguish between hosts in the same domain, SOP is too restrictive.

Parent domain traversal shortens domain name held in document.domain in the DOM to its .domain.tld (Top Level Domain) portion; wwww.my.org can be shortened to my.org but not to org.

Problem: Domain names where the last two fields define a domain, e.g. .co.uk for UK companies.

With parent domain traversal, all co.uk domains can be accessed if you have access to one company.

Browsers keep lists of exceptions to parent domain traversal.

16


Cross Site Scripting

17


Cross-site scripting (XSS) Parties involved: Attacker, client (victim), server

(‘trusted’ by the client).

Attacker places malware on a page at the server (stored XSS) or gets the victim to include the malware in a request to the server (reflected XSS).

The code is contained in the page returned by the server to the client.

The code is executed at the client with the permissions of the trusted server.

Evades client’s origin based security policy.

18


Reflected XSS User gets malicious input from attacker, e.g. by

visiting attacker’s web site, which is then included in a request to the trusted server.

Data provided by client used by server-side scripts to generate results page for user.

If unvalidated user data is included in results page (e.g. no HTML encoding), client-side code can be injected into this page.

Code will execute with permissions of trusted server.

Typical examples where client input is reflected: Search forms, custom 404 pages.

19


Reflected XSS

firewall

attacker.comuntrusted zone

trusted zone

Field:…[instr.]

Malicious instructions

encoded as data

Field:text[instr.]

‘Field:’‘text’instr.

applet with malicious

instructions

20


Stored XSS

Stored, persistent, or second-order XSS.

Data provided to a web application is stored persistently on server (in database, file system, …) and later displayed to users in a web page.

E.g., bulletin board type applications.

Every time the vulnerable web page is visited, the malicious code gets executed; attacker needs to inject script just once.

21


Threats

Execution of code on the victim’s machine.

Cookie stealing & cookie poisoning: Read or modify victim’s cookies.

Execute code in another security zone.

Execute transactions on another web site (on behalf of a user).

Compromise a domain by using malicious code to refer to internal web pages.

22


Defences

Ultimate cause of attack: Client only authenticates ‘the last hop’ of the entire page, but not the true origin of all parts of the page.

Defence 1: Do not rely on the same origin policy; try to differentiate between code and data instead.

Filter client inputs, sanitize server outputs, escape dangerous characters.

23


Escaping – a ‘counterexample’

Addslashes (defence against SQL injection) and the GBK character set (Simplified Chinese).

0xbf27 is not a valid multi-byte GBK character; as single-byte characters: 0xbf followed by 0x27 (').

Add a slash in front of the single quote: 0xbf5c27.

This is the valid multi-byte GBK character 0xbf5c followed by a single quote …

Source: Chris Shiflett http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

24


DOM-based XSS Objects like document.URL in the DOM are not

retrieved from the HTML received from the server but represent the browser’s view of the current URL.

Attacker creates page with malicious code in the URL and a request for a frame on a trusted site; the result page returned from the trusted site references document.URL in the DOM.

When the user clicks on link to the attacker’s page, the client’s browser stores the bad URL in document.URL and request the frame from the trusted site.

Script in results page references document.URL; in this way the attacker's code will also be executed.

25


Dome-based XSS

firewall


trusted zone

applet that refers to URL

malicious code in URL

sanitizeoutputs

filterinputs

Request for ‘innocent’ web page

maliciouscode

bypasseschecks

26


Cookie Stealing Web cookies stored at client in document.cookie.

Should only be included in requests to the domain that had set the cookie.

In a reflected XSS attack, the attacker’s script executing on the client may read the client’s cookie from document.cookie and send its value back to the attacker.

No violation of same origin policy; the script is executed in the context of the attacker’s web page.

27


Stealing More … Web page vulnerable to XSS can be used to capture

data from ‘secure’ pages in the same domain.

Script in XSS attack opens (almost) invisible window linked to target page in the client’s browser. E.g. page that takes over the entire browser window and

opens an inline frame to display target page, E.g. pop under window with link to target page that sends

itself to the background.

Rogue window has access to DOM of target page and can monitor the user’s input.

Endpoint of channels at the client: DOM in browser.

DOMs of linked pages can connect channels.

28


Defences Defence 2 – Authentication: Server sends

unpredictable one-time URLs to client during session establishment.

Server can then recognize these URLs as ‘its own’ and authenticate requests as originating directly from the client. One-time URLs have to be stored in a safe place

at client (e.g. private variables of a JavaScript object.)

Source: Martin Johns: SessionSafe

End points of channel at client: Application.

29


Cross site request forgery(XSRF)

30


Cross-site request forgery XSRF exploits ‘trust’ a website has in a user

to execute malware at a target website with the user’s privileges.

Parties involved: Attacker, user, target website (victim).

User is authenticated at target website (cookie, authenticated session,…).

The user has to visit the attacker’s webpage, which contains hidden malware, e.g. in an HTML form.

31


XSRF attack

When the user browses this page, the page automatically submits the form data using to a target site where the user has access.

Target authenticates request as coming from user; form data accepted by server since it comes from a legitimate user.

Evades target’s origin based security policy.

32


XSRF

firewall


target system

Form…<instr.>

Malicious instructions in

web form

user

authenticated tunnel

33


XSRF defences Ultimate cause of attack: The server only

authenticates ‘the last hop’ of the entire page, but not the true origin of all parts of the page.

Server initiated defence: Authenticate requests at the level of the Web application (‘above’ the browser).

Server sends secret (in the clear) when session is being established.

Application sends authenticators with each action: XSRFPreventionToken, e.g. HMAC(Action_Name+Secret,

SessionID); Random XSRFPreventionToken or random session cookie.

34


XSRF defences Client-side only defence for HTTP layer sessions:

Proxy between browser and network marks all URLs in incoming web pages with an unpredictable token; keeps a database associating tokens with domains.

Proxy checks all outgoing requests: If a token is found, the request did not originate in the client. Proxy then checks whether its origin matches the domain

the request is sent to. Otherwise, all authenticators (SIDs, cookies) added by the

browser are stripped from the URL.

Source: Martin Johns, RequestRodeo.

35


JavaScript hijacking

36


Web 1.0 & Web 2.0

web server

backend systems

browser

HTTPrequest

HTML +CSS data

web server

backend systems

browser

HTTPrequest

XML data,JSON

Ajax engine

Javascript HTML+CSS data

37


JavaScript hijacking (Web 2.0)

Related to XSRF, but discloses confidential data to attacker; bypasses same origin policy.

Features exploited: Ajax engine at client side sitting between browser

and web server; performs many actions automatically.

Web 2.0 applications may use JavaScript (JSON) for data transport; the main issue is not the data format but the decoding of application payloads.

38


JavaScript hijacking – phase 1

User has visits attacker’s web page that contains malware.

Attacker’s page includes data from the target application in its web page (in a script tag).

Client browser will get this data using the user’s current cookies/session (assuming that a session is open.)

So far same attack pattern as in XSRF.

39


JavaScript hijacking – phase 2

Attacker’s malware written to override the object constructor in the client’s AJAX engine.

When the server’s JSON result page is processed at the client, the modified object constructor is invoked and sends the secret data to attacker.

This execution is performed in the context of the attacker’s web page; thus it is permitted to send the captured data back to attacker.

40


JavaScript hijacking – defence

Defences against phase one: Same as for XSRF.

To defend against phase two, change execution flow at client.

Server modifies the JSON in its response so that it will not be directly executed by the browser: Prefix message with while(1); to cause an infinite loop. Put message between comment characters.

Prefix/comment removed by application; secret is thereby processed in the context of the application.

The malicious web page cannot remove the block.

Client side end point of channel: Application.

41


DNS Rebinding Attacks

42


DNS rebinding Web browsers enforce same origin policy:

Applet can only connect back to the server it was downloaded from.

To make a connection, the client’s browser needs the IP address of the server.

Authoritative DNS server resolves ‘abstract’ DNS names in its domain to ‘concrete’ IP addresses.

The client’s browser ‘trusts’ the DNS server when enforcing the same origin policy.

43


Trust is Bad for Security!

44


DNS rebinding attack

“Abuse trust”: Attacker creates attacker.com domain; binds this name to two IP addresses, to its own and to the target’s address.

Client downloads applet from attacker.com; applet connects to target’s IP address; permitted by same origin policy.

Defence: Same origin policy with IP address. D. Dean, E.W. Felten, D.S. Wallach: Java security:

from HotJava to Netscape and beyond, 1996 IEEE Symposium on Security & Privacy.

45


DNS rebinding attack Next round: Javascript, 2001.

Client visits attacker.com; attacker’s DNS server resolves this name to attacker’s IP address with short time-to-live.

Attacker rebinds attacker.com to target’s address.

Malicious script connects to attacker.com; binding has expired; browser asks again and now gets the target’s address.

Defence: Do not trust server on time-to-live; keep time yourself and pin host name to original IP address. J. Roskind: Attacks against the Netscape browser.

in RSA Conference, April 2001.

46


DNS rebinding attack

Attacker takes its application server offline; connection attempt by the malware fails.

The client’s browser might then drop the pin for that server and go back to the attacker’s DNS server to get the ‘correct’ IP address for the application server ...

Lesson: Error handling is security critical.

47


DNS rebinding attack Next round: Browser plug-ins that do their own

pinning.

More sophisticated authorisation system: Client browser refers to policy obtained from DNS server when deciding on connection requests.

Dangerous constellation: Communication path between plug-ins. Each plug-in has its own pinning database.

Attacker may use the client’s browser as a proxy to attack the target.

48


Defences

Centralize security controls; one pinning database for all plug-ins; e.g., let all plug-ins use the browser’s pins.

Do not ask DNS server for the policy but the system with the IP address a DNS name is being resolved to. Similar to reverse DNS lookup. Similar to defences against bombing attacks.

49


Conclusions You cannot enforce a security policy if you cannot

authenticate the attributes it refers to.

What precisely is the end point being authenticated? Terms like ‘Alice’ and ‘Bob’ or ‘server’ and ‘client’ are too

imprecise.

Challenge: How to authenticate the location a data item came from? It might have travelled a long way.

Challenge: How to authenticate location without a suitable infrastructure? Know thyself and double check?

50


What to look out for?

Mashups, web feeds, and syndications.

With same origin policies the fun is just starting. HTTP access control headers for cross-domain

policies. AJAX cross-domain policies.

Who will set those policies?

Who will enforce those policies?

51


Resources XSS: Cross site scripting

CERT Advisory CA-2000-02: Malicious HTML Tags Embedded in Client Web Requests

Writing Secure Code, chapter 13

XSRF: Cross site request forgery Jesse Burns: Cross Site Reference Forgery, 2005

JavaScript hijacking Brian Chess, Yekaterina Tsipenyuk O'Neil, Jacob West:

JavaScript Hijacking, 2007

DNS rebinding attacks Collin Jackson, Adam Barth, Andrew Bortz, Weidong Shao,

Dan Boneh: Protecting Browsers from DNS Rebinding Attacks, 2007

Documents

NISNet Winter School Finse 2008 1 Internet & Web Security Case Study 3: Web application security Dieter Gollmann Hamburg University of Technology [email protected]