Transcript Building Secure Mashups

Usable
∧
Building Secure Mashups
D. K. Smetters
PARC
The promise of Web 2.0
• Your data, anytime anywhere…
combined with that of
•
•
•
•
your friends
your family
your employer
anybody else’s you can get your hands on…
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
Goal
The 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?
Data
Owner
Data
Holders
Data Transformation Service
Securing mashups requires building systems designed for
flexible, ad-hoc cross-organization delegation of limited access to
sensitive data – all under easy user control.
Why is this hard?
Data Holders
Data
Owner/User
Data Transformation
Service
Data Holders
Data Transformation
Service
Data Holders
Data Holders
Data Transformation Service
Data Transformation Service
Data Holders
Data Transformation
Service
Securing mashups requires building systems designed for
flexible, ad-hoc cross-organization delegation of limited access to
sensitive data – all under easy user control.
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 Bridge
Special
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
read
the
Only
memberscan
of the
finance
current revenue
information.
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
Only the people I like
maybe when it makes us look
can see whether I’m
good. Or when its my friends,
going to the party
trying to figure out if now is the
tomorrow.
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…
…you can’t put any
stock in that – it’s
not chrome…
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…
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
It isthe
assumed that the Consumer
Consumer’s true identity. The method in
has
provided
which the Service Provider
informs
the its RSA public key in a
verified
User and the quality of the
identityway to the Service
assurance is beyond the scope
of thisin a manner which is
Provider,
specification.
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
• Security is a secondary goal
– People do care. They just care about other things more.
• Don’t make them choose
– They don’t care about understanding it in your terms.
• Love me, love my mechanism…
• This stuff is hard for people to understand.
– After 10+ years, people still screw up SSL certs more often than not.
• Whatever you think of SSL, people ought to have figured out how to make it
easier to manage by now. It’s not hard to do.
• Whatever easiest-to-deploy cr*p option makes it through the
current fragout will be with us for longer than we care to think.
– The examples used to promote various alternatives are way too simple.
• They don’t begin to enable people to evaluate how things will work down the
road.