+ All Categories
Home > Documents > Know Thyself

Know Thyself

Date post: 21-Mar-2016
Category:
Upload: farica
View: 36 times
Download: 0 times
Share this document with a friend
Description:
Know Thyself. Dieter Gollmann Hamburg University of Technology Germany. 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. - PowerPoint PPT Presentation
29
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 OWASP http://www.owasp.org OWASP Europe Conference 2008 Know Thyself Dieter Gollmann Hamburg University of Technology Germany
Transcript
Page 1: Know Thyself

Copyright © The OWASP FoundationPermission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.

The OWASP Foundation

OWASP

http://www.owasp.org

OWASP Europe Conference 2008

Know Thyself

Dieter GollmannHamburg University of TechnologyGermany

Page 2: Know Thyself

OWASP

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”?

Page 3: Know Thyself

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?

Page 4: Know Thyself

OWASP

Cross-site Scripting

firewall

attacker.comuntrusted zone

trusted zone

Formwith[instr.]

Malicious instructions

encoded as data

Formwith[instr.]

Pagewithinstr.

page with malicious

instructions

Reflected XSS

Pagewithinstr.

Stored XSS

Page 5: Know Thyself

OWASP

XSRF

firewall

attacker.comuntrusted zone

target system

formwithinstr.

form with malicious

instructions

user

authenticated tunnel

Page 6: Know Thyself

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.

Page 7: Know Thyself

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.

Page 8: Know Thyself

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.

Page 9: Know Thyself

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/addslashes-

versus-mysql-real-escape-string

Page 10: Know Thyself

OWASP

Interlude – Mobile IPv6

Page 11: Know Thyself

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!

Page 12: Know Thyself

OWASP

MN

CNhome

3: MAC(Kbm;CoA, CN, BU)

Binding update protocol

HoTI

CoTI

Challenge sent to location

HoT: K0, i

CoT: K1, j

Challenge sent to home address

binds home address to

location

[RFC 3775]

Page 13: Know Thyself

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).

Page 14: Know Thyself

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.

Page 15: Know Thyself

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.

Page 16: Know Thyself

OWASP

Cryptographically Generated Addresses (basic idea)

subnet prefix interface ID

two reserved bits

private key

hash

public key

Page 17: Know Thyself

OWASP

Back to Web applications

Page 18: Know Thyself

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

Page 19: Know Thyself

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.

Page 20: Know Thyself

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.

Page 21: Know Thyself

OWASP

DNS rebinding

Page 22: Know Thyself

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.

Page 23: Know Thyself

OWASP

Trust is Bad for Security!

Page 24: Know Thyself

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 addressD. Dean, E.W. Felten, D.S. Wallach: Java security:

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

Page 25: Know Thyself

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-to-live.

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.

Page 26: Know Thyself

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.

Page 27: Know Thyself

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.

Page 28: Know Thyself

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?

Page 29: Know Thyself

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?


Recommended