OWASP Europe Conference 2008
Know Thyself
Dieter Gollmann
Hamburg University of Technology
Germany
OWASP
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
http://www.owasp.org
Thesis
To enforce (same) origin policies, you have to
be able to authenticate origin.
Even when you are unable to authenticate the
origin of inputs provided by others, you may
still be able to authenticate your own.
Can we use an elementary security primitive
“Recognizing yourself”?
OWASP
Owls to OWASP
Web application vulnerabilities like XSS or XSRF
are a major security concern today.
Is there something to be learned from security
mechanisms developed for mobile systems?
OWASP
Cross-site Scripting
Page
with
instr.
Form
with
[instr.]
Reflected XSS
Form
with
[instr.]
page with
malicious
instructions
Page
with
instr.
trusted zone
Stored XSS
firewall
Malicious
instructions
encoded as data
attacker.com
untrusted zone
OWASP
XSRF
authenticated
tunnel
user
target system
form
with
instr.
firewall
form with
malicious
instructions
attacker.com
untrusted zone
OWASP
Cross-site scripting (XSS)
Parties involved: Attacker, client (victim), server
(‘trusted’ by client).
Attacker places malware on a page at server
(stored XSS) or gets victim to include attacker’s
code in a request to the server (reflected XSS).
Malware contained in page returned by server to
client; executed at client with permissions of the
trusted server.
Violation of an origin based security policy.
OWASP
XSRF attack
 Parties involved: Attacker, user, target website (victim).
 User authenticated at target (cookie, SSL session,…).
 User has to visit the attacker’s webpage that contains
hidden malware, e.g. in an HTML form.
 When the user browses this page, it automatically
submits the malware to a target site where the user has
access.
 Target authenticates request as coming from user; form
data accepted since it comes from a legitimate user.
 Evades target’s origin based security policy.
OWASP
Causes & Defences
Ultimate cause of XSS attack: The client only
authenticates ‘the last hop’ of the entire page,
but not the true origin of all parts of the page.
Ultimate cause of XSRF attack: The server 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 origin based policies;
differentiate between code and data instead.
Defence 2: Authenticate your own requests.
OWASP
Defence 1
 Filter client inputs, sanitize server outputs, escape
dangerous characters.
 Do you know all paths malicious code can arrive?
 DOM-based XSS!
 Do you know how filtered input is processed further?
 Will a helpful component change くor ‹ to <?
 Do you know about all interactions between different
layers of abstraction?
 Addslashes and the GBK character set (simplified Chinese):
 0xbf27  0xbf5c27 ( 0x27 encodes ‘ )
 Chris Shiflett: http://shiflett.org/blog/2006/jan/addslashesversus-mysql-real-escape-string
OWASP
Interlude – Mobile IPv6
OWASP
MIPv6 Security (RFC 3775)
Mobile node has secure tunnel to home agent
where it as a home address.
Mobile node moves and informs correspondent
node about its new care-of-address address.
Correspondent node updates its binding cache.
A malicious (mobile) node may lie about its
location; e.g. to launch a bombing attack.
Secure binding update with return routability:
Challenges sent to identity and location,
response binds identity to location.
Cryptographic keys are sent in the clear!
OWASP
Binding update protocol
[RFC 3775]
Challenge sent
to home address
HoTI
home
CN
HoT: K0, i
Challenge sent
to location
CoTI
CoT: K1, j
MN
binds home
address to
location
3: MAC(Kbm;CoA, CN, BU)
OWASP
BU Protocol
1. Mobile sends two BU init messages to the
correspondent, one via the home agent, the
other on the direct link.
2. Correspondent constructs a key for each of the
two BU init messages, returns these keys K0
and K1 independently to mobile.
3. Binding key Kbm = SHA-1(K0,K1) used by
mobile to authenticate the binding update;
authentication binds location (care-of-address)
to identity (home address).
OWASP
Ownership of addresses
Dynamic address allocation schemes checks that
a new address is still free: broadcasts query
asking whether any node on the network
already uses this address.
Squatting attack: Attacker falsely claims to have
the address that should be allocated; prevents
victim from obtaining an address in the network.
Can a node prove that it “owns” an IP address
without relying on third party (home agent, CA)?
Use public key cryptography without an PKI.
OWASP
CGA: Cryptographically Generated Addresses
Address owner creates a public key/ private key
pair; hash of the public key as interface ID in an
IPv6 address.
Mobile node signs BU information with its
private key; sends the signed BU together with
its public key to the correspondent.
Correspondent checks that the public verification
key is linked to the IP address.
Address is “certificate” for its public key.
OWASP
Cryptographically Generated Addresses (basic idea)
private key
public key
hash
subnet prefix
interface ID
two reserved bits
OWASP
Back to Web applications
OWASP
Authenticating origin
 Authentication: “Know whom you are talking to.”
 Bad definition: Computers do not talk; too narrow
generalization from communications security.
 Better: Authentication binds different elements in an IT
system, e.g. identity and location.
 Web applications: Bind parts of a page to their origin.
 This may be difficult, and may not be necessary.
 Know thyself: Recognize the parts you have contributed.
 Identification: Recognize those parts that come from the
same source.
 Pekka Nikander: identidem = same as before
OWASP
Authentication in Web applications
 XSS defence: Server sends unpredictable one-time URLs
to the client during session establishment; server can
recognize these URLs as ‘its own’ and can authenticate
requests as originating directly from the client.
 One-time URLs have to be stored in a safe place at the client.
 Source: Martin Johns: SessionSafe
 Server initiated XSRF defence: Authenticate requests at
level of the Web application (‘above’ the browser);
application sends authenticators with each action:
 XSRFPreventionToken, e.g. HMAC(Action_Name+Secret,
SessionID);
 Random XSRFPreventionToken or random session cookie.
OWASP
Authentication in Web applications
 Client-side only XSRF defence for HTTP layer sessions :
 Proxy between browser and network marks all URLs in
incoming web pages with unpredictable token; keeps
database associating tokens with domains.
 Proxy checks all outgoing requests:
 Know thyself: If a token is found, the request did not originate
in the client.
 Identification: 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.
OWASP
DNS rebinding
OWASP
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.
Client’s browser ‘trusts’ the DNS server when
enforcing the same origin policy.
OWASP
Trust is Bad for Security!
OWASP
DNS rebinding attack
“Abuse trust”: Attacker creates attacker.org
domain; binds this name to two IP addresses, to
its own and to the target’s address.
Client downloads applet from attacker.org;
applet connects to target; permitted by same
origin policy.
Defence: Same origin policy using IP address
D. Dean, E.W. Felten, D.S. Wallach: Java security:
from HotJava to Netscape and beyond, 1996 IEEE
Symposium on Security & Privacy.
OWASP
DNS rebinding attack
 Next round: Javascript, 2001.
 Client visits attacker.org; attacker’s DNS server resolves
this name to attacker’s IP address with short time-tolive.
 Attacker rebinds attacker.org to target’s address.
 Malicious script connects to attacker.org, which now is
resolved to 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.
OWASP
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.
OWASP
DNS rebinding attack
Attacker may use the client’s browser as a proxy
to attack the target.
Defence: Centralize security controls; one
pinning database for all plug-ins; e.g., let all
plug-ins use the browser’s pins.
Defence: 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.
OWASP
Conclusions
You cannot enforce a security policy if you
cannot authenticate the attributes it refers to.
Challenge: With origin based policies, how to
authenticate the location a data item came
from? It might have travelled a long way.
Which end point is being authenticated? Terms
like ‘the server’ or ‘the client’ are too imprecise.
Challenge: How to authenticate location without
a suitable infrastructure?
Know thyself and double check?
OWASP
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?
Who can authenticate their attributes?
OWASP