RIA Security - Broken By Design

RIA Security -
Broken By Design
Joonas Lehtinen
Vaadin Ltd, CEO

@joonaslehtinen
#geecon #vaadin

perjantaina 13. toukokuuta 2011

a system is
secure if it is
designed to be
secure and
there are no
bugs


no system
should be
designed to
be insecure


not all bugs
are security
holes


not all
security holes
are found and
exploited


security
broken by
design?


advertises
security holes and
makes avoiding
them harder


1. 2. 3.
RIA Security Breaking in
GWT • Architecture • PayMate
• Complexity • Attacks
Vaadin • Attack surface


Rich
Internet
Application


web 3D
platform games

business
software

web
pages

User Interface
Complexity

Web Ajax Full
Sites Sugar RIA
Plugin JavaScript

PHP Flex SmartClient

JQuery Silverlight
GWT
Wicket JavaFX
ExtJS
JSP
Dojo Client Side
JSF
Server Side
YUI
Spring MVC
ZK
ICEFaces


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

Client Side

Server Side

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


Google
Web
Toolkit


Google Web Toolkit Hosted Web
Mode Browser
Browser

Subset of IE6 Web Server
java.lang, java.util

Java to IE7
Widgetset JavaScript
Compiler
Firefox
Your Application
Your Application UI Logic
Safari

DB


Vaadin


Vaadin Framework
Web Browser Java Server or Portal

Your Servlet Servlet /
Custom Portlet /
Theme Vaadin JSF /
(optional)
Widgets JSP / ...
(vaadin.jar) (optional)

Google Web Toolkit

Vaadin Your Your User Interface
Widgets Custom
(Rendering) Widgets
(optional)
Your Business Logic


Security


“Web 1.0”
Visible data
filtering by
access
Client 5
Server SQL injection

HTML Page
DOM over HttpResponse View 4

3
Model

Parameters over
HttpRequest
Controller
2
DB
1
Parameter
parsing and
validation

Authentication


Client Side RIA
All view and
Visible data
controller code
filtering by
is sent to all
access
clients
Client 4 Server
Requested data
View to view as
XML / JSON
5
SQL injection

DOM Model
3
1

Changes to model
Controller encoded as parameters
DB
2
Parameter
Client (and thus
parsing and
view and
re-validation
controller) can
not be trusted
Authentication


Rule #1
Never trust the
browser

Server Side RIA
Visible data
filtering by
access

Client 8
Server SQL injection
9 7
TerminalAdapter

TerminalAdapter
HTML Page
over HttpResponse View 6

Automated by 5
DOM the RIA framework Model

Handled by the framework Parameters over
HttpRequest Controller
1 4
3 DB
2


Rule #2
Complexity is a
hiding-place for
security-ﬂaws

complexity
Aspect Server Side Client Side
No access to server resources - X
Web-service API design - X
Communication design - X
Client-side validation - X
Server-side validation X X
Untrusted runtime - X
Exposed runtime - X
Highly dynamic language - X

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

Attack Surface: Web 1.0

• Web page HTML (presentation)

• Form parameters

• Parameter parsing

• Parameter validation

• Cross-site scripting (XSS)


Attack Surface: Client Side RIA

• Web page DOM (presentation)

same as web 1.0
• Form parameters (for hybrid solutions)




• 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

Attack Surface: Server Side RIA

• Web page DOM (presentation)

• Form parameters (for hybrid solutions)




• 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

Breaking In


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

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

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


GWT version
Client-side RIA version Vaadin version
Server-side RIA version
Running on Client Client Side Web Toolkit ]
[ Google RIA Server[Side RIA
IT Mill Toolkit ]

User Inteface
[ Custom code ]

Web Service API Async

Web Service API
Running on Server

Web Service API Impl User Inteface
[ Custom code ]

Business Logic

DB


Case #1
Injection


SELECT NAME,ID
FROM ACCOUNT
WHERE NAME='
' OR TRUE OR ''='
' AND PASSWORD=''


attack
SQL injection


Injection

• Cures:
• Isolation: Keep data and execution
separate
• Validation: Reject suspicious data
• Escaping: Modify the data to keep it from
affecting the execution

Client Side RIA vulnerable
Server Side RIA vulnerable


Case #2
Double
validation

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


attack
rewriting client-
side validation


attack
forging http
transport


POST Data
4ï¿¿0ï¿¿7ï¿¿http://localhost:8080/paymate/client-
side/com.paymate.gwt.PayMateApplication/ï
¿¿29F4EA1240F157649C12466F01F46F60ï
¿¿com.paymate.gwt.client.PayMateServiceï
¿¿sendMoneyï¿¿Dï¿¿java.lang.Stringï
¿¿joonas@vaadin.comï¿¿1ï¿¿2ï¿¿3ï¿¿4ï¿¿2ï¿¿5ï¿¿6ï
¿¿999999ï¿¿7ï¿¿
-99999


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);
};

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

Server Side RIA not vulnerable


Case #3
Forging
references

Client

1. Client asks for service

2. Service request is delegated to business logic
Web Service API

3. List of accessible object is requested
Business Logic Process

ref ref
Data Model

Object List Object A Object B


Client

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

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

Web Service API Web Service API

4. Info about wrong object is
retrieved. Data model trusts the
2. List of accessible object is requested reference!

ref
Data Model

Object List Object A Object B


attack
requesting data
with forged ids


Forging references

• Cures:
• Never pass any data-model level
references to the client
• Do all the access checks for each call
from client

Server Side RIA not vulnerable


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


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


Rule #4
There will be
bugs

summary


Rule #1
Never trust the browser
Rule #2
More complexity - less security
Rule #3
Large surface is hard to defend
Rule #4
There will be bugs


Questions
Comments

joon as@vaadin.com
+358-40-5035001
sky pe://joonaslehtinen


RIA Security - Broken By Design

More Related Content

What's hot

Viewers also liked

Similar to RIA Security - Broken By Design

RIA Security - Broken By Design