RIA Security - Broken By Design

3,983 views

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
3,983
On SlideShare
0
From Embeds
0
Number of Embeds
1,907
Actions
Shares
0
Downloads
81
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

RIA Security - Broken By Design

  1. 1. RIA Security - Broken By Design Joonas Lehtinen Vaadin Ltd, CEO @joonaslehtinen #geecon #vaadinperjantaina 13. toukokuuta 2011
  2. 2. a system is secure if it is designed to be secure and there are no bugsperjantaina 13. toukokuuta 2011
  3. 3. no system should be designed to be insecureperjantaina 13. toukokuuta 2011
  4. 4. not all bugs are security holesperjantaina 13. toukokuuta 2011
  5. 5. not all security holes are found and exploitedperjantaina 13. toukokuuta 2011
  6. 6. security broken by design?perjantaina 13. toukokuuta 2011
  7. 7. advertises security holes and makes avoiding them harderperjantaina 13. toukokuuta 2011
  8. 8. 1. 2. 3. RIA Security Breaking in GWT • Architecture • PayMate • Complexity • Attacks Vaadin • Attack surfaceperjantaina 13. toukokuuta 2011
  9. 9. Rich Internet Applicationperjantaina 13. toukokuuta 2011
  10. 10. web 3Dplatform games business software web pages User Interface Complexityperjantaina 13. toukokuuta 2011
  11. 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 ICEFacesperjantaina 13. toukokuuta 2011
  12. 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. 13. Google Web Toolkitperjantaina 13. toukokuuta 2011
  14. 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 DBperjantaina 13. toukokuuta 2011
  15. 15. Vaadinperjantaina 13. toukokuuta 2011
  16. 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 Logicperjantaina 13. toukokuuta 2011
  17. 17. Securityperjantaina 13. toukokuuta 2011
  18. 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 Authenticationperjantaina 13. toukokuuta 2011
  19. 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 Authenticationperjantaina 13. toukokuuta 2011
  20. 20. Rule #1 Never trust the browserperjantaina 13. toukokuuta 2011
  21. 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 2perjantaina 13. toukokuuta 2011
  22. 22. Rule #2 Complexity is a hiding-place for security-flawsperjantaina 13. toukokuuta 2011
  23. 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 - Xperjantaina 13. toukokuuta 2011
  24. 24. Rule #3 Large surface: easy to attack, hard to defendperjantaina 13. toukokuuta 2011
  25. 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. 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 directlyperjantaina 13. toukokuuta 2011
  27. 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 directlyperjantaina 13. toukokuuta 2011
  28. 28. Breaking Inperjantaina 13. toukokuuta 2011
  29. 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. 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 DBperjantaina 13. toukokuuta 2011
  31. 31. Case #1 Injectionperjantaina 13. toukokuuta 2011
  32. 32. perjantaina 13. toukokuuta 2011
  33. 33. SELECT NAME,ID FROM ACCOUNT WHERE NAME= OR TRUE OR = AND PASSWORD=perjantaina 13. toukokuuta 2011
  34. 34. attack SQL injectionperjantaina 13. toukokuuta 2011
  35. 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 vulnerableperjantaina 13. toukokuuta 2011
  36. 36. Case #2 Double validationperjantaina 13. toukokuuta 2011
  37. 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 useperjantaina 13. toukokuuta 2011
  38. 38. attack rewriting client- side validationperjantaina 13. toukokuuta 2011
  39. 39. attack forging http transportperjantaina 13. toukokuuta 2011
  40. 40. 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
  41. 41. 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
  42. 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 vulnerableperjantaina 13. toukokuuta 2011
  43. 43. Case #3 Forging referencesperjantaina 13. toukokuuta 2011
  44. 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 Bperjantaina 13. toukokuuta 2011
  45. 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 Bperjantaina 13. toukokuuta 2011
  46. 46. attack requesting data with forged idsperjantaina 13. toukokuuta 2011
  47. 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 vulnerableperjantaina 13. toukokuuta 2011
  48. 48. These bugs are just plain stupid! [our team is smart enough to avoid them]perjantaina 13. toukokuuta 2011
  49. 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 systemperjantaina 13. toukokuuta 2011
  50. 50. Rule #4 There will be bugsperjantaina 13. toukokuuta 2011
  51. 51. summaryperjantaina 13. toukokuuta 2011
  52. 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 bugsperjantaina 13. toukokuuta 2011
  53. 53. Questions Comments joon as@vaadin.com +358-40-5035001 sky pe://joonaslehtinenperjantaina 13. toukokuuta 2011

×