SlideShare a Scribd company logo

Secure Mashups

•Download as PPT, PDF•
•
K
kriszyp

The document discusses techniques for creating secure mashups, including server-side and client-side approaches. It describes challenges around trust between participants and potential exploits. It provides an overview of tools like ADsafe, Caja, and dojox.secure that aim to sandbox code by restricting language features and access. Dojox.secure in particular provides a full framework for loading, validating, and restricting access to DOM for third-party widgets in a controlled manner.

Related slideshows

Cross site scripting
Cross site scriptingCross site scripting
Cross site scripting
 
Securing your Movable Type installation
Securing your Movable Type installationSecuring your Movable Type installation
Securing your Movable Type installation
 
Cross site scripting XSS
Cross site scripting XSSCross site scripting XSS
Cross site scripting XSS
 
1 of 32
Secure Mashups Kris Zyp Introduction
Interconnectedness Web continues to grow in interconnectedness of data
Overview More services and data sources More consumers want utilize this services Tools ADsafe Caja dojox.secure
Techniques of mashups Server Side Mashup
Techniques of mashups Client Side Mashup
Trust between mashup participants Exploit between participants Consumer gaining excess privileges Services exploiting Consumers
Server Side Mashups Public Content - Easy Protected Content - Authorization necessary
OAuth
Client Side Mashups Directly utilize broker (the browser)‏ Direct communication Exploits: Cross site scripting Cross site request forgery
Providing services for mashups Publicly accessible resources are simple, provide as many transports as possible Protected resources more complicated
Services protecting resources Authentication and authorization MUST be differentiated Cross site request forgery is a major exploit Cookies should be used for authentication Authorization May require user interaction May be based on origin (Referer header or Access-Control-Origin header)‏
JSON Hijacking CSRF Vulnerability + top-level Arrays = Exploit Modified JSON Commenting {}&&[...] Best to have good CSRF protection
Client Side Transports: JSONP GET /resource/?callback=myfunc myfunc({“foo”:”bar”});
Client Side Transports: Fragment Identifier Messaging Outer Frame http://mashup.com / Inner Frame http://service.com /#message_for_the_outer_frame
Client Side Transport: Subspace Sandboxed JSONP Very complicated, more requests DNS requirements
Client Side Transport: window.name Data is loaded in a sandboxed frame, the mashup is protected from malicious code Client side handling UI interaction possible Efficient
Client Side Transport: postMessage Iframe based Allows client side handling User interaction can be utilized for authorization of resources Efficient transport Conventions/standards be developed for proxying requests
Client Side Transport: Native XHR with W3C CS-AC Coming soon Efficient Secure, no code execution More complicated authorization
Third party widgets We want third part code to execute, but in a controlled manner Protect the environment, provide access to a subset of the DOM Restrict JavaScript features
ADsafe Disables features in JavaScript that prevent containment/sandboxing Global variables [index], this, ==, != Properties: apply,call,callee,caller,constructor,eval, prototype,this,unwatch,valueOf,watch, and anything starting or ending with __ with, eval
ADsafe ADsafe compliant JavaScript can only access objects that are “given” to it. ADsafe scripts can be safely sandboxed, and one can control what objects are accessible.
Caja Object capability version of JavaScript (same idea as ADsafe)‏ Larger set of language features (less major restrictions)‏ Uses code translation
Dojo Secure Full framework for loading, validating, and providing a safe set of library functions and safe access to the DOM. Provides loading registry with different loading mechanims Uses ADsafe style language constraints Provides |this| within class constructors
Dojo Secure Provides access to the DOM (a facade), with the standard API, that is restricted Provides a library API (with no namespacing, no need in a global-less environment)‏ Full framework: loading, validation, and DOM sandboxing
Using dojox.secure //Register cross-domain loading mechanism dojox.io.xhrWindowNamePlugin(" http://siteA.com "); //Create sandbox mySandbox = dojox.secure.sandbox(dojo.byId("sandbox")); //Securely load, validate, and evaluate HTML or JavaScript mySandbox.loadJS(" http://siteA.com/widget.js "); mySandbox.loadHTML(" http://siteA.com/widget.html ");
dojox.secure Create HTML or JavaScript element and document provides access to the DOM innerHTML and DOM methods available Follow sanboxing rules (avoid restricted operators and globals)‏ Full library available: query, byId, style, forEach, Class, fromJson , etc. Use Class to build methods with this operator Accompanied by Demo
Secure Mashups
Properly differentiate authorization and authentication
Avoid insecure loading mechanisms and cookie only based authorization
dojox.secure to create client-side mashups Mutually suspicious components can coexist Eliminate vulnerabilities between widgets
Secure Mashups
 

More Related Content

Secure Mashups

  • 1. Secure Mashups Kris Zyp Introduction
  • 2. Interconnectedness Web continues to grow in interconnectedness of data
  • 3. Overview More services and data sources More consumers want utilize this services Tools ADsafe Caja dojox.secure
  • 4. Techniques of mashups Server Side Mashup
  • 5. Techniques of mashups Client Side Mashup
  • 6. Trust between mashup participants Exploit between participants Consumer gaining excess privileges Services exploiting Consumers
  • 7. Server Side Mashups Public Content - Easy Protected Content - Authorization necessary
  • 9. Client Side Mashups Directly utilize broker (the browser)‏ Direct communication Exploits: Cross site scripting Cross site request forgery
  • 10. Providing services for mashups Publicly accessible resources are simple, provide as many transports as possible Protected resources more complicated
  • 11. Services protecting resources Authentication and authorization MUST be differentiated Cross site request forgery is a major exploit Cookies should be used for authentication Authorization May require user interaction May be based on origin (Referer header or Access-Control-Origin header)‏
  • 12. JSON Hijacking CSRF Vulnerability + top-level Arrays = Exploit Modified JSON Commenting {}&&[...] Best to have good CSRF protection
  • 13. Client Side Transports: JSONP GET /resource/?callback=myfunc myfunc({“foo”:”bar”});
  • 14. Client Side Transports: Fragment Identifier Messaging Outer Frame http://mashup.com / Inner Frame http://service.com /#message_for_the_outer_frame
  • 15. Client Side Transport: Subspace Sandboxed JSONP Very complicated, more requests DNS requirements
  • 16. Client Side Transport: window.name Data is loaded in a sandboxed frame, the mashup is protected from malicious code Client side handling UI interaction possible Efficient
  • 17. Client Side Transport: postMessage Iframe based Allows client side handling User interaction can be utilized for authorization of resources Efficient transport Conventions/standards be developed for proxying requests
  • 18. Client Side Transport: Native XHR with W3C CS-AC Coming soon Efficient Secure, no code execution More complicated authorization
  • 19. Third party widgets We want third part code to execute, but in a controlled manner Protect the environment, provide access to a subset of the DOM Restrict JavaScript features
  • 20. ADsafe Disables features in JavaScript that prevent containment/sandboxing Global variables [index], this, ==, != Properties: apply,call,callee,caller,constructor,eval, prototype,this,unwatch,valueOf,watch, and anything starting or ending with __ with, eval
  • 21. ADsafe ADsafe compliant JavaScript can only access objects that are “given” to it. ADsafe scripts can be safely sandboxed, and one can control what objects are accessible.
  • 22. Caja Object capability version of JavaScript (same idea as ADsafe)‏ Larger set of language features (less major restrictions)‏ Uses code translation
  • 23. Dojo Secure Full framework for loading, validating, and providing a safe set of library functions and safe access to the DOM. Provides loading registry with different loading mechanims Uses ADsafe style language constraints Provides |this| within class constructors
  • 24. Dojo Secure Provides access to the DOM (a facade), with the standard API, that is restricted Provides a library API (with no namespacing, no need in a global-less environment)‏ Full framework: loading, validation, and DOM sandboxing
  • 25. Using dojox.secure //Register cross-domain loading mechanism dojox.io.xhrWindowNamePlugin(" http://siteA.com "); //Create sandbox mySandbox = dojox.secure.sandbox(dojo.byId("sandbox")); //Securely load, validate, and evaluate HTML or JavaScript mySandbox.loadJS(" http://siteA.com/widget.js "); mySandbox.loadHTML(" http://siteA.com/widget.html ");
  • 26. dojox.secure Create HTML or JavaScript element and document provides access to the DOM innerHTML and DOM methods available Follow sanboxing rules (avoid restricted operators and globals)‏ Full library available: query, byId, style, forEach, Class, fromJson , etc. Use Class to build methods with this operator Accompanied by Demo
  • 29. Avoid insecure loading mechanisms and cookie only based authorization
  • 30. dojox.secure to create client-side mashups Mutually suspicious components can coexist Eliminate vulnerabilities between widgets
  • 32.