RIA Security - Broken By Design
Upcoming SlideShare
Loading in...5
×
 

RIA Security - Broken By Design

on

  • 3,982 views

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

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

Statistics

Views

Total Views
3,982
Slideshare-icon Views on SlideShare
2,084
Embed Views
1,898

Actions

Likes
0
Downloads
73
Comments
0

3 Embeds 1,898

https://vaadin.com 1498
http://vaadin.com 398
http://www.techgig.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    RIA Security - Broken By Design RIA Security - Broken By Design Presentation Transcript

    • RIA Security - Broken By Design Joonas Lehtinen Vaadin Ltd, CEO @joonaslehtinen #geecon #vaadinperjantaina 13. toukokuuta 2011
    • a system is secure if it is designed to be secure and there are no bugsperjantaina 13. toukokuuta 2011
    • no system should be designed to be insecureperjantaina 13. toukokuuta 2011
    • not all bugs are security holesperjantaina 13. toukokuuta 2011
    • not all security holes are found and exploitedperjantaina 13. toukokuuta 2011
    • security broken by design?perjantaina 13. toukokuuta 2011
    • advertises security holes and makes avoiding them harderperjantaina 13. toukokuuta 2011
    • 1. 2. 3. RIA Security Breaking in GWT • Architecture • PayMate • Complexity • Attacks Vaadin • Attack surfaceperjantaina 13. toukokuuta 2011
    • Rich Internet Applicationperjantaina 13. toukokuuta 2011
    • web 3Dplatform games business software web pages User Interface Complexityperjantaina 13. toukokuuta 2011
    • 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 ICEFacesperjantaina 13. toukokuuta 2011
    • 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
    • Google Web Toolkitperjantaina 13. toukokuuta 2011
    • 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 DBperjantaina 13. toukokuuta 2011
    • Vaadinperjantaina 13. toukokuuta 2011
    • 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 Logicperjantaina 13. toukokuuta 2011
    • Securityperjantaina 13. toukokuuta 2011
    • “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 Authenticationperjantaina 13. toukokuuta 2011
    • 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 Authenticationperjantaina 13. toukokuuta 2011
    • Rule #1 Never trust the browserperjantaina 13. toukokuuta 2011
    • 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 2perjantaina 13. toukokuuta 2011
    • Rule #2 Complexity is a hiding-place for security-flawsperjantaina 13. toukokuuta 2011
    • 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 - Xperjantaina 13. toukokuuta 2011
    • Rule #3 Large surface: easy to attack, hard to defendperjantaina 13. toukokuuta 2011
    • Attack Surface: Web 1.0 • Web page HTML (presentation) • Form parameters • Parameter parsing • Parameter validation • Cross-site scripting (XSS)perjantaina 13. toukokuuta 2011
    • 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 directlyperjantaina 13. toukokuuta 2011
    • 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 directlyperjantaina 13. toukokuuta 2011
    • Breaking Inperjantaina 13. toukokuuta 2011
    • 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
    • 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 DBperjantaina 13. toukokuuta 2011
    • Case #1 Injectionperjantaina 13. toukokuuta 2011
    • perjantaina 13. toukokuuta 2011
    • SELECT NAME,ID FROM ACCOUNT WHERE NAME= OR TRUE OR = AND PASSWORD=perjantaina 13. toukokuuta 2011
    • attack SQL injectionperjantaina 13. toukokuuta 2011
    • 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 vulnerableperjantaina 13. toukokuuta 2011
    • Case #2 Double validationperjantaina 13. toukokuuta 2011
    • 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 useperjantaina 13. toukokuuta 2011
    • attack rewriting client- side validationperjantaina 13. toukokuuta 2011
    • attack forging http transportperjantaina 13. toukokuuta 2011
    • POST Data4ï¿¿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ï¿¿ -99999perjantaina 13. toukokuuta 2011
    • var xhr = document.body.childNodes[5].contentWindow.XMLHttpRequest;Override the original XMLHttpRequest implementationxhr.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
    • 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 vulnerableperjantaina 13. toukokuuta 2011
    • Case #3 Forging referencesperjantaina 13. toukokuuta 2011
    • 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 Bperjantaina 13. toukokuuta 2011
    • 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 Bperjantaina 13. toukokuuta 2011
    • attack requesting data with forged idsperjantaina 13. toukokuuta 2011
    • 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 vulnerableperjantaina 13. toukokuuta 2011
    • These bugs are just plain stupid! [our team is smart enough to avoid them]perjantaina 13. toukokuuta 2011
    • 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 systemperjantaina 13. toukokuuta 2011
    • Rule #4 There will be bugsperjantaina 13. toukokuuta 2011
    • summaryperjantaina 13. toukokuuta 2011
    • 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 bugsperjantaina 13. toukokuuta 2011
    • Questions Comments joon as@vaadin.com +358-40-5035001 sky pe://joonaslehtinenperjantaina 13. toukokuuta 2011