53
Joonas Lehtinen Vaadin Ltd, CEO RIA Security - Broken By Design @joonaslehtinen #geecon #vaadin perjantaina 13. toukokuuta 2011

RIA Security - Broken By Design

  • Upload
    jojule

  • View
    4.149

  • Download
    2

Embed Size (px)

DESCRIPTION

Rich Internet Applications (RIA) provide desktop-like usability with web deployment model. The benefits of this combination are obvious and RIA is now common a choice for the presentation layer in many applications. Unfortunately, moving logic from the server to an untrusted client may open up security holes that would not be present in the page-oriented "Web 1.0" architecture. In this presentation we will take a look at client- and server-side RIA architectures from the security angle, identify some of the most common security problems and discuss strategies for avoiding them. We'll go through an example application implemented in both architectures and demonstrate the problems. Java-based RIA frameworks, Google Web Toolkit and Vaadin, are used in the examples, but the demonstrated principles are applic

Citation preview

Page 1: RIA Security - Broken By Design

Joonas LehtinenVaadin Ltd, CEO

RIA Security - Broken By Design

@joonaslehtinen#geecon #vaadin

perjantaina 13. toukokuuta 2011

Page 2: RIA Security - Broken By Design

a system is secure if it is

designed to be secure and

there are no bugs

perjantaina 13. toukokuuta 2011

Page 3: RIA Security - Broken By Design

no system should be designed to be insecure

perjantaina 13. toukokuuta 2011

Page 4: RIA Security - Broken By Design

not all bugs are security holes

perjantaina 13. toukokuuta 2011

Page 5: RIA Security - Broken By Design

not all security holes are found and exploited

perjantaina 13. toukokuuta 2011

Page 6: RIA Security - Broken By Design

security broken by design?

perjantaina 13. toukokuuta 2011

Page 7: RIA Security - Broken By Design

advertises security holes andmakes avoiding them harder

perjantaina 13. toukokuuta 2011

Page 8: RIA Security - Broken By Design

RIAGWTVaadin

Security • Architecture • Complexity • Attack surface

Breaking in • PayMate • Attacks

1. 2. 3.

perjantaina 13. toukokuuta 2011

Page 9: RIA Security - Broken By Design

Rich Internet

Application

perjantaina 13. toukokuuta 2011

Page 10: RIA Security - Broken By Design

User InterfaceComplexity

webpages

businesssoftware

3Dgames

webplatform

perjantaina 13. toukokuuta 2011

Page 11: RIA Security - Broken By Design

WebSites

PHP

JSPJSF

Wicket

Spring MVC

AjaxSugar

JQuery

YUI

Dojo

FullRIA

Client SideServer Side

ExtJSGWT

ICEFaces

Flex

JavaFX

Plugin JavaScript

SilverlightSmartClient

ZK

perjantaina 13. toukokuuta 2011

Page 12: RIA Security - Broken By Design

Client Side

Server Side

UI logic runs in browser(as JavaScript or in plugin)

UI logic runs in server(framework updates UI in browser)

perjantaina 13. toukokuuta 2011

Page 13: RIA Security - Broken By Design

GoogleWeb

Toolkit

perjantaina 13. toukokuuta 2011

Page 14: RIA Security - Broken By Design

Java toJavaScriptCompiler

Subset of

java.lang, java.util

Widgetset

Your Application UI

IE6

IE7

Firefox

Safari

Web Browser

Web Server

Your Application

Logic

DB

HostedMode

Browser

Google Web Toolkit

perjantaina 13. toukokuuta 2011

Page 15: RIA Security - Broken By Design

Vaadin

perjantaina 13. toukokuuta 2011

Page 16: RIA Security - Broken By Design

Java Server or Portal

Servlet

Web Browser

Google Web Toolkit

VaadinWidgets(Rendering)

YourCustomWidgets(optional)

YourCustomTheme(optional)

VaadinWidgets(vaadin.jar)

Your User Interface

Your Business Logic

Servlet /Portlet / JSF / JSP / ...(optional)

Vaadin Framework

perjantaina 13. toukokuuta 2011

Page 17: RIA Security - Broken By Design

Security

perjantaina 13. toukokuuta 2011

Page 18: RIA Security - Broken By Design

“Web 1.0”

DOM

Client Server

ViewHTML Page

over HttpResponse

Controller

Model

Parameters overHttpRequest

DB2

3

4

5

1

Parameterparsing andvalidation

Authentication

SQL injection

Visible datafiltering by

access

perjantaina 13. toukokuuta 2011

Page 19: RIA Security - Broken By Design

Client Side RIA

DOM

Client Server

View

Controller

Model

DB2

3

4

5

1

Requested datato view as

XML / JSON

Changes to modelencoded as parameters

Parameterparsing andre-validation

Authentication

SQL injection

Visible datafiltering by

access

Client (and thus view and

controller) can not be trusted

All view and controller code is sent to all

clients

perjantaina 13. toukokuuta 2011

Page 20: RIA Security - Broken By Design

Rule #1Never trust the

browser

perjantaina 13. toukokuuta 2011

Page 21: RIA Security - Broken By Design

Server Side RIA

DOM

Client Server

ViewHTML Pageover HttpResponse

Controller

Model

Parameters overHttpRequest

DB4

5

6

2

Term

inalAdapter

Term

inalAdapter

Automated bythe RIA framework

3

7

1

9

8 SQL injection

Visible datafiltering by

access

Handled by the framework

perjantaina 13. toukokuuta 2011

Page 22: RIA Security - Broken By Design

Rule #2Complexity is a hiding-place for security-flaws

perjantaina 13. toukokuuta 2011

Page 23: RIA Security - Broken By Design

complexityAspect Server Side Client Side

No access to server resources - XWeb-service API design - XCommunication design - XClient-side validation - XServer-side validation X XUntrusted runtime - XExposed runtime - XHighly dynamic language - X

perjantaina 13. toukokuuta 2011

Page 24: RIA Security - Broken By Design

Rule #3Large surface: easy to attack, hard to defend

perjantaina 13. toukokuuta 2011

Page 25: RIA Security - Broken By Design

Attack Surface: Web 1.0

• Web page HTML (presentation)

• Form parameters

• Parameter parsing

• Parameter validation

• Cross-site scripting (XSS)

perjantaina 13. toukokuuta 2011

Page 26: RIA Security - Broken By Design

Attack Surface: Client Side RIA

• Web page DOM (presentation)

• Form parameters (for hybrid solutions)

• Parameter parsing

• Parameter validation

• Cross-site scripting (XSS)

• UI logic can be

• Evaluated: Black-box changes to white-box!

• Changed

• Web services - a lot of API is exposed and can be called directly

sam

e as

web

1.0

perjantaina 13. toukokuuta 2011

Page 27: RIA Security - Broken By Design

Attack Surface: Server Side RIA

• Web page DOM (presentation)

• Form parameters (for hybrid solutions)

• Parameter parsing

• Parameter validation

• Cross-site scripting (XSS)

• UI logic can be

• Evaluated: Black-box changes to white-box!

• Changed

• Web services - a lot of API is exposed and can be called directly

perjantaina 13. toukokuuta 2011

Page 28: RIA Security - Broken By Design

Breaking In

perjantaina 13. toukokuuta 2011

Page 29: RIA Security - Broken By Design

[ no relation to paymate.com.au or paypal.com ]

Local demo http://localhost:8080/paymate/

Online demo http://vaadin.com/web/joonas/wiki/-/wiki/Main/RIA%20Security

perjantaina 13. toukokuuta 2011

Page 30: RIA Security - Broken By Design

Web Service API Impl

Web Service API

User Inteface

Web Service API Async

User Inteface

Server-side RIA version[ IT Mill Toolkit ]

Client-side RIA version[ Google Web Toolkit ]

[ C

ust

om

code ]

Runnin

g o

n C

lient

[ C

ust

om

code ]

Runnin

g o

n S

erv

er

DB

Business Logic

GWT versionClient Side RIA

Vaadin versionServer Side RIA

perjantaina 13. toukokuuta 2011

Page 31: RIA Security - Broken By Design

Case #1Injection

perjantaina 13. toukokuuta 2011

Page 32: RIA Security - Broken By Design

perjantaina 13. toukokuuta 2011

Page 33: RIA Security - Broken By Design

SELECT NAME,ID FROM ACCOUNT WHERE NAME='

' OR TRUE OR ''='' AND PASSWORD=''

perjantaina 13. toukokuuta 2011

Page 34: RIA Security - Broken By Design

SQL injectionattack

perjantaina 13. toukokuuta 2011

Page 35: RIA Security - Broken By Design

Injection

• Cures:

• Isolation: Keep data and execution separate

• Validation: Reject suspicious data

• Escaping: Modify the data to keep it from affecting the execution

vulnerable

Server Side RIAClient Side RIA

vulnerable

perjantaina 13. toukokuuta 2011

Page 36: RIA Security - Broken By Design

Case #2Double validation

perjantaina 13. toukokuuta 2011

Page 37: RIA Security - Broken By Design

Missing double validation

• It is often convenient to do some data validation in the user interface logic

• Attacker can always bypass any validation done in the browser

• Thus everything must be validated (again) in the server!

• Lack of double validation is almost impossible to notice in testing or normal use

perjantaina 13. toukokuuta 2011

Page 38: RIA Security - Broken By Design

rewriting client-side validation

attack

perjantaina 13. toukokuuta 2011

Page 39: RIA Security - Broken By Design

forging http transport

attack

perjantaina 13. toukokuuta 2011

Page 40: RIA Security - Broken By Design

4ï¿¿0ï¿¿7ï¿¿http://localhost:8080/paymate/client-side/com.paymate.gwt.PayMateApplication/ï¿¿29F4EA1240F157649C12466F01F46F60ï¿¿com.paymate.gwt.client.PayMateServiceï¿¿sendMoneyï¿¿Dï¿¿java.lang.Stringï¿¿[email protected]ï¿¿1ï¿¿2ï¿¿3ï¿¿4ï¿¿2ï¿¿5ï¿¿6ï¿¿999999ï¿¿7ï¿¿

POST Data

-99999

perjantaina 13. toukokuuta 2011

Page 41: RIA Security - Broken By Design

var xhr = document.body.childNodes[5].contentWindow.XMLHttpRequest;Override the original XMLHttpRequest implementation

xhr.prototype.originalSend = xhr.prototype.send;xhr.prototype.send = function(a) {

! Create UI for our hack tool

var panel = document.createElement("DIV");! panel.innerHTML = "<textarea id='postdata' cols=80 rows=20> "+ "</textarea><br/><button id='postbutton'>Post</button>";! document.body.appendChild(panel);! document.getElementById('postdata').value=a;

Do the sending when the button is pressed

! var t = this; document.getElementById('postbutton'). addEventListener("click",function() {! ! t.originalSend(document.getElementById('postdata').value);! ! document.body.removeChild(panel);! }, true);};

perjantaina 13. toukokuuta 2011

Page 42: RIA Security - Broken By Design

Double validation

• Cures:

• Never skip server-side validation

• Code review is a must - testing does not help

• Never think server-validation could be seen as “extra work” that will be added later in the project

vulnerable

Server Side RIAClient Side RIA

not vulnerable

perjantaina 13. toukokuuta 2011

Page 43: RIA Security - Broken By Design

Case #3Forging references

perjantaina 13. toukokuuta 2011

Page 44: RIA Security - Broken By Design

Object AObject List Object B

Business Logic Process

Web Service API

ref ref

Client

1. Client asks for service

2. Service request is delegated to business logic

3. List of accessible object is requested

Data

Model

perjantaina 13. toukokuuta 2011

Page 45: RIA Security - Broken By Design

Object AObject List Object B

Web Service API

Client

1. Client asks for list of objects,references are returned

4. Info about wrong object isretrieved. Data model trusts the

reference!2. List of accessible object is requested

Data

Model

3. More info about object is requested, with forged reference

ref

Web Service API

ref

ref

perjantaina 13. toukokuuta 2011

Page 46: RIA Security - Broken By Design

requesting data with forged ids

attack

perjantaina 13. toukokuuta 2011

Page 47: RIA Security - Broken By Design

Forging references

• Cures:

• Never pass any data-model level references to the client

• Do all the access checks for each call from client

vulnerable

Server Side RIAClient Side RIA

not vulnerable

perjantaina 13. toukokuuta 2011

Page 48: RIA Security - Broken By Design

These bugs are just plain stupid![our team is smart enough to avoid them]

perjantaina 13. toukokuuta 2011

Page 49: RIA Security - Broken By Design

really?I can assure that Yes No

I would never do mistakes like these

Not even under pressure, late at night, on deadline

And neither would the rest of the team, no-one

Or the guys working for our off-shore contractor

And we rigorously double review all of our code

And trust we would spot 100% of these

And we review all legacy code too

We will newer have any “black boxes” in our system

perjantaina 13. toukokuuta 2011

Page 50: RIA Security - Broken By Design

Rule #4There will be

bugs

perjantaina 13. toukokuuta 2011

Page 51: RIA Security - Broken By Design

summary

perjantaina 13. toukokuuta 2011

Page 52: RIA Security - Broken By Design

Rule #1Never trust the browserRule #2More complexity - less securityRule #3Large surface is hard to defendRule #4There will be bugs

perjantaina 13. toukokuuta 2011