The document discusses security issues with rich internet applications (RIAs). It outlines four main rules: 1) never trust the browser, as client-side code can be manipulated; 2) more complex architectures introduce more opportunities for vulnerabilities; 3) client-side RIAs have a larger attack surface than server-side RIAs; and 4) all software will contain bugs, so architectures should be designed to minimize security risks from bugs. It provides examples of SQL injection, validation bypassing, and request forging to illustrate how client-side RIAs can be vulnerable if these principles are not followed.
9. Rich
Internet
Application
perjantaina 13. toukokuuta 2011
10. web 3D
platform games
business
software
web
pages
User Interface
Complexity
perjantaina 13. toukokuuta 2011
11. 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
perjantaina 13. toukokuuta 2011
12. UI logic runs in browser
(as JavaScript or in plugin)
Client Side
Server Side
UI logic runs in server
(framework updates UI in browser)
perjantaina 13. toukokuuta 2011
13. Google
Web
Toolkit
perjantaina 13. toukokuuta 2011
14. 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
perjantaina 13. toukokuuta 2011
16. 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
perjantaina 13. toukokuuta 2011
18. “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
perjantaina 13. toukokuuta 2011
19. 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
perjantaina 13. toukokuuta 2011
20. Rule #1
Never trust the
browser
perjantaina 13. toukokuuta 2011
21. 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
perjantaina 13. toukokuuta 2011
22. Rule #2
Complexity is a
hiding-place for
security-flaws
perjantaina 13. toukokuuta 2011
23. 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
perjantaina 13. toukokuuta 2011
24. Rule #3
Large surface:
easy to attack,
hard to defend
perjantaina 13. toukokuuta 2011
25. Attack Surface: Web 1.0
• Web page HTML (presentation)
• Form parameters
• Parameter parsing
• Parameter validation
• Cross-site scripting (XSS)
perjantaina 13. toukokuuta 2011
26. Attack Surface: Client Side RIA
• Web page DOM (presentation)
same as web 1.0
• 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
27. 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
29. 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 ]
perjantaina 13. toukokuuta 2011
30. 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
perjantaina 13. toukokuuta 2011
31. Case #1
Injection
perjantaina 13. toukokuuta 2011
33. SELECT NAME,ID
FROM ACCOUNT
WHERE NAME='
' OR TRUE OR ''='
' AND PASSWORD=''
perjantaina 13. toukokuuta 2011
34. attack
SQL injection
perjantaina 13. toukokuuta 2011
35. 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
perjantaina 13. toukokuuta 2011
36. Case #2
Double
validation
perjantaina 13. toukokuuta 2011
37. 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
38. attack
rewriting client-
side validation
perjantaina 13. toukokuuta 2011
39. attack
forging http
transport
perjantaina 13. toukokuuta 2011
41. 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
42. 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
Client Side RIA vulnerable
Server Side RIA not vulnerable
perjantaina 13. toukokuuta 2011
43. Case #3
Forging
references
perjantaina 13. toukokuuta 2011
44. 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
perjantaina 13. toukokuuta 2011
45. 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
perjantaina 13. toukokuuta 2011
46. attack
requesting data
with forged ids
perjantaina 13. toukokuuta 2011
47. Forging references
• Cures:
• Never pass any data-model level
references to the client
• Do all the access checks for each call
from client
Client Side RIA vulnerable
Server Side RIA not vulnerable
perjantaina 13. toukokuuta 2011
48. These bugs are
just plain stupid!
[our team is smart enough to avoid them]
perjantaina 13. toukokuuta 2011
49. 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
50. Rule #4
There will be
bugs
perjantaina 13. toukokuuta 2011
52. 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
perjantaina 13. toukokuuta 2011