NISNet Winter School Finse 2008 1 Internet & Web Security Case Study 3: Web application security...
-
date post
18-Dec-2015 -
Category
Documents
-
view
215 -
download
0
Transcript of NISNet Winter School Finse 2008 1 Internet & Web Security Case Study 3: Web application security...
1
NISNet Winter School Finse 2008
Internet & Web SecurityCase Study 3: Web application security
Dieter Gollmann
Hamburg University of Technology
2
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
Agenda
Web processing model (simplified)
Sessions
Same Origin Policy
Cross-site scripting
Cross-site request forgery
JavaScript hijacking
DNS Rebinding attack
6
NISNet Winter School Finse 2008
Web processing model
web server
backend systems
browser
HTTPrequest
HTML +CSS data
client
server
7
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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!
13
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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.
17
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
Dome-based XSS
firewall
attacker.comuntrusted zone
trusted zone
applet that refers to URL
malicious code in URL
sanitizeoutputs
filterinputs
Request for ‘innocent’ web page
maliciouscode
bypasseschecks
26
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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.
30
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
XSRF
firewall
attacker.comuntrusted zone
target system
Form…<instr.>
Malicious instructions in
web form
user
authenticated tunnel
33
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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.
36
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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.
42
NISNet Winter School Finse 2008
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.
44
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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
NISNet Winter School Finse 2008
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