Re: Towards a model of web browser security

On Mon, Aug 17, 2015 at 1:15 PM, Nick Doty <npdoty@w3.org> wrote:
> I like seeing exercises to model security explicitly and I'm sure we could
> use more practice on this for the Web. I would be very curious to hear what
> you experts have to say as feedback on this particular model (what is it
> useful for? what would make it more useful?) and what other models might
> already be out there to look at.
>
> http://emergentchaos.com/archives/2015/08/towards-a-model-of-web-browser-security.html

A general comment... There's a good document available at "[W3C Web
Security IG] Strews report",
https://lists.w3.org/Archives/Public/public-web-security/2015May/0003.html.

> For me, I noticed a couple things missing or different than I would have
> expected. This might just be a diff of my personal mental model of Web
> security, but hopefully the feedback is still useful. I'm sending these
> comments to Adam, and will point him to this thread to see other comments.

Yes :)

"Interception is a valid use case" is the show stopper for me. As you
know, data has three states: (1) data at rest (client and/or server);
(2) data in transit (between client and server); and (3) data on
display (usually at the client). "Interception is a valid use case"
destroys any assurances for the second state of data.

For me and the organizations I consult with, it positions web apps in
one of two places:

    (1) limit web apps to low value data so breaches are mostly inconsequential
    (2) accept the risk associated with using web apps when they transport data

Many disagree; to each their own. But since this is a security
document, it serves the community to enumerate the risk so others can
make an informed decision.

> * sites are composed of resources from many servers (currently displayed as
> entirely separate boxes)
> Sites often embed other sites (for example, iframes, or script tags), and
> most of our difficult security questions seem to arise from this fact. Users
> probably don't understand how web pages are composed and the ability of
> messaging between origins via iframes and the like is a common cause of
> security/privacy leakages.
>
> * the network mediates access between browsers and sites (currently
> displayed as unrelated boxes)
> Attacks both of surveillance and of insertion of malicious data/code rely on
> the network infrastructure being between the browser and the server/site.
> Passive vs. active attacks, etc. are hard to explain without the network
> being in between the user and the site.
>
> * certificates and TLS (currently missing)
> Certificate authorities seem like an important, distinct entity not marked
> on the diagram yet. TLS (transport) encryption is a primary method for
> supporting both confidentiality and integrity. The certificate authority
> model introduces an important layer of trust: if the CA is breached, what
> are the implications? etc.

It sounds like you should break out SSL/TLS security and PKIX security.

TLS security would include things like, say, server SSL/TLS
configurations, and the risk from say, accepting unauthenticated data
and then acting upon it (re: TLS 1.3 and fast start, 0-time to fist
byte, and all that goodness).

PKIX security would look at frameworks like PKI use in the internet,
and include things like a CA breach. By the way, a nice history is
available at CACert Risk History: http://wiki.cacert.org/Risk/History.

> * origins (currently missing)
> Security on the Web depends on the concept of origins, which are not
> described in this model. This matters both because of the
> composability/embeddedness question above, but also because the same-origin
> policy expects isolation of data between origins. For example, the local
> storage container should be kept distinct between origins.
> http://tools.ietf.org/html/rfc6454

Origin security in practice is an interesting concept. On one hand,
they have it. On the other hand, they circumvent the origins security
with SOP-busting technologies, like iFrames, CORS and XHR.

And an origin is defined differently based on context. The definition
of an origin for a cookie is different than a document.

> * plugins surround tabs?
> In the current diagram, the plugins box surrounds all the tab boxes. It
> seems that in most browsers, tabs (windows) can talk to the browser without
> going through a plugin.

The interactions with plug-ins is challenging. For example, a plug-in
was never able to change the Address Bar indicators, like the shield
used to indicate a "secure site". But they were able to snoop data
between origins.

But its also changing. Chrome is deprecating the NPAPI
(https://www.chromium.org/developers/npapi-deprecation).

> Perhaps the broader question is: is this a model of Web browser security or
> the Web security model? I think the two are closely related anyway, but the
> current diagram seems more focused on browser security issues rather than
> Web security issues.

Your threat model should probably include DNS and the CA/Browser forum.

DNS should be modeled because browsers mostly reject anything related
to it, but SSL/TLS certificate Domain Validation (DV) is indirectly
dependent upon it due to the WHOIS database and/or verification
emails.

You should consider modeling the CA/Browser as a threat because things
like OV certificates sprouted out of it. Companies can join a program
like GeoRoot and then issue Organization Validated (OV) certificates.
The immediate problem is a company can mint certificates for any web
property (and not just the properties they own or manage). The
underlying problem with the GeoRoot-type programs and the OV
certificates is loss of the independent 3rd party that validated the
requests combined with the refusal to use PKIX name constraints.

Another threat from the browser side of the CA/Browser Forums is the
failure to ensure compliance with Inclusion Polices, and then the
failure to follow through with punishment for transgressors. Trustwave
taught the CAs is OK to eschew policy and legal agreements. It still
leaves a bitter taste in my mouth
(https://bugzilla.mozilla.org/show_bug.cgi?id=724929).

Received on Monday, 17 August 2015 19:53:13 UTC