Post on 26-Mar-2015
Building Secure Mashups
D. K. SmettersPARC
Usable∧
The promise of Web 2.0
• Your data, anytime anywhere…
• your friends• your family• your employer• anybody else’s you can get your hands on…
combined with that of
What’s a mashup?• Inputs:
– User-generated data • often personal user-generated data, such as photographs • generated by the mashup user and their friends, family, favorite
presidential canidates, cat, neighbors, and so on– Social network information
• another form of private, and even valuable data – Public or semi-public data sources
• databases of available information (e.g. Google Maps) with varying guarantees of correctness and constraints on use
– Private data sources• e.g. corporate data subject to some form of access control,
subscription data, etc.
• Outputs:– User-focused result (e.g. a visualization)– A derived data source
• input for yet another mashup
GoalThe goal of all browser/mashup security mechanisms is to ensure that:
• The data the user intends• Is processed in the way the user intends• By the entities s/he chooses• Subject to additional constraints imposed by others with interest in
that data.
And nothing else.
Why is this hard?
Securing mashups requires building systems designed for flexible, ad-hoc cross-organization delegation of limited access to sensitive data – all under easy user control.
Data OwnerData
Owner
Data Holders
Data Holders
Data Transformation Service
Data Transformation Service
Data HoldersData HoldersWhy is this hard?
Securing mashups requires building systems designed for flexible, ad-hoc cross-organization delegation of limited access to sensitive data – all under easy user control.
Data Owner/User
Data Owner/User
Data HoldersData Holders
Data Transformation ServiceData Transformation Service
Data Transformation ServiceData Transformation Service
Data Transformation ServiceData Transformation Service
Data HoldersData Holders
Data HoldersData Holders
Data Transformation ServiceData Transformation Service
Data HoldersData Holders
Data Transformation ServiceData Transformation Service
Approaches
Avoid
Use only public (or semi-public) data.
Embrace
All your credentials are belong to us.
Reduce it to a previously solved problem
Mashup services provided by trusted data holders themselves. (Or other sites the user chooses to trust.)
Looking Under the Lamppost
Identify sets of a priori interesting data and enable delegation of access to those.
Building a BridgeSpecial privileges, accounts and relationships established to enable access to particular data for a particular purpose.
Outsourcing
Identity provider or authorization service handles the problem and manages the relationship with the user(s).
Usability Challenges
Who are the users?
• Mashup developers– and the people who build their toolkits, etc.
• Owners and creators of data to be mashed• Administrators of any of the hosts involved• End users of resulting mashups
Connecting the Providers They Intend
Identifying Data
Should site www.weasels.com have access to your “Misc” folder?
•Does it mean the same Misc folder I think it means?•What did I put in that folder anyway?
Specifying Policies
Only members of the finance department can read the current
revenue information.
Only members of the finance department can read the current
revenue information.
Only the people I like can see whether I’m
going to the party tomorrow.
Only the people I like can see whether I’m
going to the party tomorrow.
Only members of the finance department can read the current
revenue information.
But only if they’re like, just going to read it. Not if they’re going to, say, average it against the public
data from other companies in our sector. Except maybe when it makes us look good. Or when its my friends, trying to figure
out if now is the time to look for a different job, or..
Only members of the finance department can read the current
revenue information.
But only if they’re like, just going to read it. Not if they’re going to, say, average it against the public
data from other companies in our sector. Except maybe when it makes us look good. Or when its my friends, trying to figure
out if now is the time to look for a different job, or..
Making the user an ally
• How can the user figure out what the system is doing (or trying to do)?
• How can they decide what to do when something goes wrong?
This is hard enough when users are “face to face” with the site they need to authenticate – what about when it’s buried in a processing pipeline?
Love me, love my mechanism…
I used to use Facebook, but I got
off it because I wasn’t happy with their iframe isolation…
I used to use Facebook, but I got
off it because I wasn’t happy with their iframe isolation…
…oh, they have an expired cert, but at
least it’s ev…
…oh, they have an expired cert, but at
least it’s ev…
…you can’t put any stock in that – it’s
not chrome…
…you can’t put any stock in that – it’s
not chrome…
The Error Attack
As long as configuration errors are common, attacks can masquerade successfully as errors – and users will be acting rationally if they ignore them.
What’s a developer to do?the Service Provider MUST inform the User if it is unable to assure the Consumer’s true identity. The method in which the Service Provider informs the User and the quality of the identity assurance is beyond the scope of this specification.
It is assumed that the Consumer has provided its RSA public key in a verified way to the Service Provider, in a manner which is beyond the scope of this specification.
• Mashup developers are focused on mashing, not securing.• Will use the easisest mechanism available.• Hopefully, that’s the right one.
• Users are at the mercy of the mechanisms chosen by the services they want or need to use.
Points to Remember