WebAppSec TPAC F2F -- 23 Oct 2018

<jeffh> webex coordinates ?

<jeffh> k thx

<dveditz> https://www.w3.org/2011/webappsec/webex.html

<dveditz> at the top, not the regular meeting at the bottom

<dveditz> ckerschb present+

<dveditz> jcj_moz present+

<jeffh> bummer

<dveditz> you can hear us then?

<jeffh> yeah

<dveditz> ping me if you need a voice

<inserted> scribenick: wseltzer

mkwst: reviewing agenda
... Mixed Content, reviewing WPT results
... something wrong with the Edge tests
... already a CFC to move forward
... Referrer Policy
... looking at different numbers of tests, if the test errors out early, then doesn't continue

<iclelland> Can’t set the topic, but the agenda is https://bit.ly/webappsec-tpac-2018-agenda

mkwst: chrome needs to work on css integrations
... Secure Contexts

[links to tests are in the agenda]

scribe: for the core features good support
... Upgrade Insecure Requests

mkwst: think all these 4 are fairly solid
... should we look at the issues?
... or keep going and review issues offline?

dveditz: any issues that need discussion?

mkwst: open bug against referrer policy regarding how it works in module scripts
... think it should work like CSP

dveditz: in referrer policy, anne opened a bug because changing something in fetch

mkwst: not normative changes to the spec

Newer Stuff

mkwst: Clear site data
... executionContexts may be too chrome-specific a name.
... do other implementers see wide use, or could we change?

dveditz: don't think it's a large number
... should be doable to change

mkwst: curious whether FF implementers have feedback on whether the spec needs more specificity

Ben: issue 49

<wseltzer_screen> https://github.com/w3c/webappsec-clear-site-data/issues/49

Ben: edge case encountered by a real site trying to use the feature

mkwst: curious if there's more work we need to do before moving to CR
... we have 2 implementations

Eric: don't have a formal opinion

dveditz: there's an issue re merging with storage

mkwst: I don't think we should make this spec go away

dveditz: I don't either; reference Storage where necessary

mkwst: having own document is a good way of explaining to developers why it exists
... think it's fine to move to CR

ericlaw: ^

mkwst: for chrome, it was intentional to delete

ericlaw: I think it's the opposite now

mkwst: suggest filing a bug against chrome
... and should make the spec clearer

<dveditz> mike filed https://github.com/w3c/webappsec-clear-site-data/issues/52

mkwst: talk about integration with storage when annevk comes in

Credential Management

mkwst: state of affairs: Credential Management has 2 open bugs from WebAuthn
... both related to async
... goal to review JeffH's patch for 100
... and copying mechanism
... merge those, then split doc in 2
... Framework, navigator.credentials. Webauthn relies on
... other piece is support for password credential
... that split is still the plan
... and move ahead with framework
... CFC to move to CR
... what's the right process for split?

wseltzer: they don't need to go back through FPWD

jeffh: I just raised another issue earlier today
... 129

<wseltzer_screen> https://github.com/w3c/webappsec-credential-management/issues/129

jeffh: 100 we should merge. mostly fixes 92

<wseltzer_screen> https://github.com/w3c/webappsec-credential-management/issues/92

mkwst: we should be able to deal with 100 this week

<wseltzer_screen> https://github.com/w3c/webappsec-credential-management/issues/128

mkwst: what would you like us to do
... we want to do what makes sense for webauthn
... which of the algorithms do you want?

jcj_moz: short form of what we want is wheichever version is easiest to define unambiguously
... sanity things wrt not copying large buffers around
... making sure we don't have race conditions

mkwst: question was web-visible
... copying not web-visible, transfer would be
... don't know if anyone is using/relying

jcj_moz: ff does a copy

mkwst: that's an argument for putting copy into the spec

jcj_moz: buffers aren't large

mkwst: would you put a PR together?

jcj_moz: JeffH and I will

jeffh: we're going to go with copy

mkwst: thanks for putting a PR together; I'll do my best to merge it

<wseltzer_screen> https://github.com/w3c/webappsec-credential-management/issues/129

jeffh: tri-state return: credential, null, error
... we realized we never returned null

mkwst: believe for passwords and federations, we distinguish between impossible, e.g. type error, and credential missing
... think we should leave the null, though you don't ever have to return it

jeffh: probably need to add some text to the spec, making clear it's ok not to return null

mkwst: where would you look for that?
... maybe where we talk about extension points
... I'll work with jcj_moz
... Plan for CredMan is to resolve thse three issues, make sure webauthn has what it needs to progress
... we'll split the spec and issue a CfC to move framework to CR
... make sense

[jcj and jeffh +1]

[no objections]

mkwst: would like to have a conversation about password credential and federated credential

<jeffh> see https://github.com/w3c/webappsec-credential-management/issues/129#issuecomment-432135517

mkwst: but need to see more
... let's put that into future section

Require-SRI-For

mkwst: allow devs to require SRI for page elements, a CSP directive defined in SRI
... both FF and chrome have implementations, neither has shipped
... from folks in the room, is this something reasonable to ship?
... do we need to deal with scripts that can't assert integrity beforehand, e.g. import scripts

<jeffh> https://w3c.github.io/webappsec-subresource-integrity/#opt-in-require-sri-for

mkwst: there should be a way to define metadata for scripts
... worth shipping it in current state?
... without that granularity?
... blocking seems more future-compatible

dveditz: FF didn't block ,and that's why we haven't shipped

ArturJanc: same thing is important in CSP nonces and Trusted Types

ericlaw: does something inclued the new token when added?

mkwst: my feeling, people don't think this is useful until we have way o fdealing with imports in workers and in modules

dveditz: is it useful at all?

mkwst: heard interest from github
... might make sense for us to ship to get attention in TC39
... talk to folks re module loading (anne and domenic)

<dveditz> freddyb: are you on the call?

mkwst: folks here seem to think it's not worth shipping in current state, but would be with modules

Chartering

mkwst: charters, then coffee!

<wseltzer_screen> https://www.w3.org/2011/webappsec/charter-2017.html

mkwst: charter expires at the end of the year
... it sets the scope of patent commitments
... looking at this with an eye to what new we want to do
... e.g. iclelland is here re Feature Policy
... sounds in-scope, do we need to add anything?
... can you tell us about goals of feature policy?

iclelland: Feature Policy meant to be a more or less consistent mechanism for allowing web features
... like sandbox, turns off attribute in subframe and all below it
... preventing dangerous features

mkwst: not just "dangerous" but annoying too
... e.g. sync XHR
... "distasteful"?
... is that "information and content flows"?

iclelland: feature policy spec doesn't define features
... it's a mechanism for other specs to hook into

mkwst: is there a registry?

iclelland: no

mkwst: feature policy is the framework by which mechanism is introduced

<wseltzer_screen> mkwst: reviewing https://www.w3.org/2011/webappsec/charter-2017.html#scope

mkwst: my intuition is that the scope defined here is broad enough to include what we want to bring in
... skim through things we're looking at down the day

koto: Trusted types
... mech for website to reduce its DOM exposure
... attack surface reduction
... to XSS

mkwst: and vuln mitigation
... origin policy, lets you set, e.g. CSP for default on a site
... might ultimately merge with app manifest
... performance, as well as security
... falls into manageability
... Sanitization

dveditz: sanitization, should we adopt something like dompurify?

mkwst: sanitization is in charter
... Spectre mitigation, hints re isolation
... attack surface reduction
... sec-metadata
... SRI2, Mixed Content 2, Intersection Observer 2, Suborigins, clearly covered
... HTTP state tokens and Storage Access API, elsewhere
... Permissions conversations
... Domain affiliation
... mechanism for indicating that 2 domains are affiliated.
... password management
... please look at the charter with your AC reps / lawyers, to make sure you can commit to it and do the work we want to do
... come back to the group if you have issues, but if not, I'd suggest we re-use it

<mkwst> wseltzer: A primary audience for the charter is lawyers who need to know what patent commitments they'll be making.

<mkwst> ... I think we have a good scope here, I don't think we need to massage things too much to contain the kinds of things we're talking about.

<mkwst> ... Not restricted from adding new deliverables, as long as they're within scope.

<mkwst> ... So we can iterate, take on new work, etc.

<mkwst> ... One question I heard raised was "Should we include the word 'privacy' in scope?"

<mkwst> ... Lots of what we're looking at includes privacy implications.

<mkwst> ... We're looking at both.

<mkwst> ... Should we give that signal to readers?

mkwst: in the charter, we make reference to PING
... as the group for security reviews
... but they're not chartered for normative documents

<freddyb> â/q dveditz

mkwst: the things we're considering for privacy are also security-related
... e.g. cookies
... would be within existing scope
... talk with PING

<freddyb> s/â\/q dveditz//

mkwst: giving an explicit venue for doing normative work seems fine
... Please tell us if you're not OK with the scope

[break return in 30 minutes]

<dveditz> scribenick: dveditz

Content Security Policy

mkwst: what do we need to do to call CSP-3 done, and look at CSPEE
... CSP3 is huge and been around a long time
... look at "Changes from level 2" -- long and getting longer. 12 different items
... plus the entire structure of the spec changed
... Getting to the point of diminishing returns. Artur can you talk about how Google is using CSP?

ArturJanc: we're very happy with the nonce-based model, not using whitelists
... with the 'strict-dynamic' keyword
... we're hardening our policies with removing unsafe-eval and so on, but strict-dynamic is the main successful change
... Not adopted widely, but used in some large players like Dropbox and others
... Optimizely published a blog saying that nonces is how they got CSP deployed, after trying to use whitelists for a long time
... For 20 most sensitive apps 95% (?) is using CSP, overall maybe 60% (for Chrome and Firefox visitors)

mkwst: working well against reflected XSS. we'll talk in the futures section about other kinds of XSS
... the most recent changes have been splitting script-src so we can govern script blocks vs attributes (ditto style)
... Chrome has implemented this but I don't know if it's behind a flag or shipping yet
... What needs to happen in the spec so we can call it "done". I know of 4 things that are either contentious or widely supported.
... the contentious issue is how workers ought to function
... should dedicated workers have their own CSP or inherit from the document?
... first iteration we inherited from the document. Then we changed serviceworkers, shared workers AND dedicated workers to have their own policies and not inherit.
... then changed dedicated workers _back_ to inheriting from their document (following the script model) but shared and service workers continued to follow the iframe model (their own CSP) because they work with multiple documents

wanderview: as an implementer there's benefit to treating all these the same, and making dedicated workers different makes it complicated
... also caused confusion with other specs
... my opinion treating dedicated workers as shared workers would be better

mkwst: what about worklets?

wanderview: they also create globals, but they are opaque origins. I don't know where they ended up
... it's much more restricted in what they do and you can't observe them (not same origin) so they don't have the same issues as dedicated workers

mkwst: what's Mozilla's implementation? I think workers get their own policy

ckerschb: yes. I think we should treat all workers the same and dedicated workers shouldn't inherit the CSP

wanderview: what happens with a blob: url frame?

mkwst: they are like about:blank iframes and inherit the CSP
... [we don't know what Edge or Safari to]

wanderview: it would be nice if we had a definition of inheritance of all the different things
... like referrer policy, and csp, etc... a centralized definition

mkwst: a bunch of it is defined in HTML. I can't remember if we define this for CSP _in_ CSP or if it's in HTML
... [looks at spec] we do it in CSP

wanderview: service workers have the same problem defining the controller, rather than centralized

mkwst: this sounds like Architecture that is Technical in nature. If only there were some group that defined things like that?

slightlyoff: TAG doesn't actually "define" things like this, we review the work of various WGs for consistency with an overall model

ArturJanc: most sites in general define a CSP per origin, so most policies end up being the same whether they're inherited or specified

mkwst: my worry is not that they're different but that people forget to set a policy on their dedicated worker if it doesn't inherit.

dveditz: browsers could issue warnings for workers without a CSP whose document has one, could help implementors

mkwst: 3 other things we need to decide if they're in CSP3.
... 1) we don't give granular enough control over eval() -- should they take hashes?
... can eval be turned off and on in different sections of a document lifetime?
... Dropbox and google have found places where this might be useful
... 2) confinement vs XSS prevention.
... issues 92 and 287 --- limit the destinations for webrtc stuff
... hard because we don't know who your peer is going to be, and a variety of intermediaries (ICE, TURN, STUN)
... could punt on complexity and just have a "no-webrtc" switch
... might be able to use connect-src
... this is not about XSS, this is about restricting the sending of information. the mechanisms we have like this are not exhaustive, so if this is a goal of CSP then we are not meeting that goal
... it must be possible to enumerate explicit connections and we could prevent though, but we can't enumerate side channels and prevent them.

ArturJanc: there's a prefetch/preconnect issue, importScripts if you are using nonces (vs a whitelist), postMessage, and navigation
... navigate-to might prevent that

mkwst: cure53 has a repo "HTTPLeaks" with lots of examples
... some entities do use CSP for confinement, but not really exfiltration prevention
... If we want "exfiltration" to be part of the model there's work to do. I want someone to volunteer to do that work. if no one does then I don't want to take it on

ericlaw_: developers think it's a feature of the spec, or want it to be

koto: for exfil to be robust there needs to be additional isolation primitives. CSP can only do a reduced model

mkwst: it's possible to enumerate every request and control it, but it will take a lot of work, and I'm not convinced it would be worthwhile

annevk: what about the webrtc case specifically

mkwst: there seems to be interest and I'd take it if people are going to do it
... we could add an implementation note that all new things should be governed by default-src

[breaking for lunch]

<ericlaw_> Resuming at 1330

jeffh: are you still on the call?

your computer seems to be

if so we can't hear you again

<scribe> scribenick: dveditz

Web Application Vulnerability Trends in the Wild

ArturJanc: a talk about the practical problems and vulnerabilities we see in the wild
... data comes from the Google web bug reward program. Google has 3: chrome, web, and "everything else". give out about $1Million a year, thousands of bugs that tell us about trends
... [slide on reward program categories and payout amounts]
... [slide on google's web app ecosystem -- very diverse stacks]
... 4 major languages (java c++ python go)
... 16 html template systems, dozens of server-side frameworks
... 619 distinct applications under *.google.com
... 2 billion lines of code
... lots of 3rd party code
... hundreds of acquired companies with various code stacks
... traditional SDL/hardening approaches have limits, so emphasize hardening the platform
... == Vulnerabilities ==
... [slide, Mozilla website vuln categories from jvehent]
... [slide similar data from HackerOne]
... [Slide Google VRP pie chart since 2014]
... $3.4 million total, $2.6million is web platform bugs, then "everything else"
... everything else is hardware, android apps, acquisitions...
... Web platform bugs aren't direct attacks on servers, but attacks on logged-in users
... XSS is dominant (slide shows just shy of 3/4), CSRF and Clickjacking together are about 1/8, "other" is about 1/8
... main causes of XSS: code without escaping and misuse of innerHTML are about 1/6 each
... green (1/6) is template system without escaping or disabled excaping
... insecure URL handling (maybe 1/8?) other JS primitives are a narrow slice, "other" is between 1/4 and 1/3
... [slide web platform vulns as % of total]
... decreasing over time but still the majority
... main vuln classes are XSS in various forms, followed by CSRF, XSSI, clickjacking etc.
... long tail of issues caused by platform weaknesses of the platform:
... XS-Search, size leaks, pixel-perfect leaks, etc
... I claim there are 3 major classes of vulns in web applications
... 1) lack of transport safety. No confidentiality/integrity -- all bets are off
... vulns: use of HTTP, non-secure cookies, mixed scripting
... specs: HSTS, mixed content, UIR
... 2) injections (XSS). attacker scripts running in a vulnerable origin --> all bets are off
... specs: CSP etc
... 3) forced loading of endpoints from victim's origin
... broad class of purpose-specific attacks that violate integrity or confidentiality
... forced inclusion: CSRF, clickjacking
... confidentiality leaks: XSSI, XS-Search, timing attacks, pixel-perfect attacks,
... note: getting worse as new APIs are added to the platform. More info leaks
... not giving much help to developers for these
... specs: SameSite cookies, CORB/CORP, Sec-Metadata, COWP, Isolate-Me
... Some work doesn't fall under the previous categories. iframe sandbox is useful, COWL,
... attacks on trusted resources: SRI, referrer policy
... direct attacks on the browser or the user
... Call to ACTION: we should build mechanisms that solve these problems for web developers
... Secure Transport, Injections, cross-origin leaks
... If these mechanisms work as opt-in, we might in the future be able to turn them on by default which will be more secure -- developers won't have to know about them

mkwst: questions on the presentation?

<ericlaw_> Would another example be the ability to look at cross-origin frames.length?

mkwst: koto will talk about Trusted Types (https://gadgets.kotowicz.net/poc/Trusted_Types_TPAC_2018.pdf).

koto: close to the vulnerabilties at Google as part of the VRP and as a researcher
... gives me ideas on how to help devs not create the problems in the first place
... DOM XSS is the most common issue in our apps, more than 50%
... and a growing problem
... Trusted Types can help!
... [slide on DOM XSS]
... "location.hash => bar.innerHTML"
... growing because complexity of client-side code, easy to introduce and hard to prevent and detect
... DOM API has ~70 sinks that can result in JS execution. innerHTML, eval(), etc.
... commonly used in applications. DOM API "insecure by default"

(input) => document.querySelector('log').innerHTML = input; vulnerability or not? hard to reason about where "input" came from

scribe: sources far from sinks, complex data flows. static checks don't work reliably
... (we tried and failed at Google). manual review is infeasable
... dynamic taint-tracking and fuzzing has small code coverage
... we have mitigations internally at Google by using safe HTML types rather than strings
... wrappers for strings representing values known to be safe in certain HTML/DOM contexts
... SafeHTML, SafeURL, TrustedResourceURL, others...
... producing the typed values is safe by construction or sanitization,
... or is reviewed manually (goog.html,uncheckedconversions.safeUrlFromStringKnownToSatisfyTypeContract())
... for the latter each use has to be reviewed by the security team
... consuming these is safe, compiler prevents the use of native sinks.
... SafeHTMLTypes makes DOM safe by default. Only the code producing a safe type can introduce XSS
... this reduces the risk and review burden
... very successful at preventing XSS
... though we still have some DOM XSS (compiler understanding != browser view). some code is not compiled
... "Trusted Types" is building these types into the platform rather than requiring our in-house compiler
... 1) API to create string-wrapping objects for a few types
... TrustedHTML, TrustedURL, TrustedScriptURL, TrustedScript (e.g. onclick handler)
... 2) opt-in enformcement: make DOM XSS sinks accept only the typed objects. turns out to be fairly easy to do in the browser (at least in Chrome's experience)
... without enforcement: backwards compatibility using a polyfill defining the types, no breakage of app
... with enforcement: minimize DOM XSS attack surface, only code producing the types can introduce XSS
... apps define Trusted Type "policies" (functions to do the sanitization/enforce rules)
... only code calling an insecure policy can cause DOM XSS. But the ability to create them means this can be rolled out incrementally across an app. Somewhat like using a script-src nonce
... Enforcement and policy creation -- for now CSP header "trusted-types foo bar" -- ok to create foo or bar policy but not baz policy, whatever the policies happen to be
... multiple policies can coexist: a strict one for comment editing, a custom one for app template system
... Chrome has landed an implementation behind a flag (crbug/739170), and a polyfill
... integration trials underway
... Summary: turn DOM XSS from easy to introduce/hard to detect to easy to detect and hard to introduce
... easy to implement in chrome: 1Q 2-intern project
... backward compatible through polyfill
... would like feedback/questions/concerns

lukasz: if you have introduced this why do you still have so many DOM XSS

<johnwilander> Question for Koto (trying to avoid waking up the others in the house): How do we make Trusted Types simple enough for developers and avoid the "policy fatigue" that has affected CSP adoption?

<johnwilander> Or should we view Trusted Types as mostly for the big players on the web?

koto: sometimes compiler can't tell the type of a node if it's dynamic, or similar

ArturJanc: also it's often in code that wasn't compiled

koto: (answering johnwilander) I think it's tractable. we target consumers of types, often the frameworks and not the individual developers.

<littledan> Q: A previous version of this proposal (presented at TC39) specially tried to restrict to literal strings. Are you no longer interested in that aspect?

koto: there aren't thousands of policies, they're in the frameworks and developers just use the frameworks

<johnwilander> Follow-up: Would it be a mandatory thing in those frameworks?

koto: I started writing policies for various samples, and found that the policies were similar so maybe we just have libraries of policies

littledan: A previous version of this proposal (presented at TC39) specially tried to restrict to literal strings. Are you no longer interested in that aspect?

koto: we thought getting changes in TC39 would take too long

littledan: not necessarily if you used tagged strings

johnwilander: (followup from above)

<johnwilander> Thanks, Koto!

koto: I don't think we can come up with a mandated opt-out mechanism

Intersection Observer 2

stephen: [demo of clickjacking examples of a payment widget]
... Intersection Observer V1 works for measuring ad impressions. only detects overflow and clip-path clipping. Does not understand other kinds of occlusion

<mkwst> https://szager-chromium.github.io/IntersectionObserver/

stephen: IO2 will include an "isVisible" flag, an absolute guarantee from the browser that nothing is blocking this.
... OK to report false-negatives (say it's not visible when it is) but never allowed to say it's visible when it's not
... 2 aspects I really like -- all the code runs in the iframe, doesn't have to depend on the parent for anything (if the browser is reliable)
... current requires teams crawling the web looking for problematic uses of a widget, this mechanism enforces it right in the browser.

mkwst: this is an extension of the work Brad Hill started in this group. have you talked to folks at facebook or others?

stephen: we've talked to people in Google (fraud teams) and they're interested. trying to line up convesations with FB and paypal.

@@: just heard back from Facebook and they're interested

wanderview: why can't this be polyfilled?

stephen: you could polyfill the mutation events, but you can't detect occlusion because the parent is cross-origin
... I came to this from the 3rd party iframe POV, but also useful for 1st party frames

<johnwilander> We do not want to encourage more third-party scripts in the first-party context.

<johnwilander> Yes, we should make Intersection Observer a pure iframe thing to encourage *less* third-party scripts in the first-party context.

<ericlaw_> Does this attempt to solve for more than visibility and occlusion? What about motion (either of the frame, jumping under the mousedown) or of the window (foreground window disappears, and you've clicked into background window)?

stephen: I don't like being too controlling, but I hear what you're saying
... common pattern in the wild -- top page has an ad network script with an iframe and the actual ad iframe below that, often with script running in all 3 contexts
... (answering eric's question) potential timing attacks detecting transition times. This proposal doesn't solve that. We have a proposal for an "intervention" in chromium that we'll reject input events on cross-origin iframes that have moved within 500ms
... proposal has been up on github for a while and mostly crickets. Would like feedback from browser vendors

<mkwst> https://github.com/w3c/IntersectionObserver/issues/295

[break]

back at 15:40

<johnwilander> If this group doesn't want to talk about anti tracking stuff, we should talk about forking off a privacy working group (I know there's a privacy interest group).

<mkwst> scribenick: mkwst

SRI2

bertil: Usability study of downloads on the web.
... Do people use integrity checksums?
... No.,
... Easy to trick folks.
... Most obvious way to do verification would be to extend SRI to include downloads.
... By adding `integrity` to `<a>`.
... And `<img>`.
... Thread on public-webappsec at https://lists.w3.org/Archives/Public/public-webappsec/2018Sep/0011.html.
... How can this be done in the context of the W3c?
... Folks have said it was the intent of the spec earlier to verify the integrity of more resource types.
... Hasn't been done yet.
... Is this of interest?

mikeoniell: What's the use case?

bertil: Folks don't do integrity checking for downloads. Prevents attackers from substituting the target with a malicious binary.

mikeoneill: For images?

bertil: Referencing an image someone else hosts. If they change it, I don't want to show it.
... Could be extended to other types of resources as well.

dveditz: I'd like to see SRI for downloads.
... Everything that has a `src` could have an `integrity` attribute.

koto: For images, progressive jpeg?

dveditz: Yes. That was one of the things we cared about, but punted on it because streaming is hard.

annevk: If there's integrity data, we get all the data, then do the check, then pass it on. No progressiveness.

<ericlaw_> linkfingerprints ?

<ericlaw_> https://www.gerv.net/security/link-fingerprints/

<dveditz> ericlaw_: sri _is_ linkfingerprints, essentially

<dveditz> IETF rejected the "on the URL" form

<ericlaw_> "on the URL" being "on the A element"?

<dveditz> https://www.w3.org/TR/SRI/#acknowledgements

annevk: We'd need to put CORS into the navigation algorithn,

<dveditz> no, linkfingerprints abused the URL hash. had the advantage that as you copied the URL around the new place would continue to enforce the fingerprint

mkwst: I kinda want to do that anyway, given CORS-RFC1918.

annevk: Also form submission changes.

mkwst: We had similar conclusions last year. Looks like it might move this time, which is great!

<dveditz> IETF owns the definition of http urls, and they rejected that approach

<dveditz> so SRI put it in HTML

yutaka: `<link rel="preload">` is not hooked up to SRI?
... w3c/preload#127
... https://github.com/w3c/preload/issues/127

yoav: I was pushing back on this.
... Because it's pushing the burden to developers. Which is bad.
... But SRI content can't be preloaded (double-downloads). Which is also bad.
... If implementation burdens, we should implement it.

mkwst: Sure. We should do it, but not because it fixes a bug in Chrome. It's reasonable to enable integrity checks for prefetch initself, but Chrome should support prefetch without the integrity check.

<dveditz> q

Feature Policy

ian: Feature Policy has been in incubation in WICG for a while.
... Mostly stable.
... Shipped in Chrome.
... Implemented in Firefox.
... And in parts by Apple.
... Referenced by HTML.
... It would be nice to push it out of incubation.
... We think it fits well in WebAppSec.
... WDYT?

yoav: The process for graduation is to ask the chairs nicely, and indicate that there's a working group that would pick it up.

mkwst: Any objections? If not, I'll send a CfC to the list for folks to consider asynchronously.

<dveditz> [no objections]

mkwst: Ok. I'll send a CfC to the list, Ian will buy Yoav coffee, and we'll be good to go.

<dveditz> scribenick: dveditz

CSPEmbeded Enforcement

mkwst: a mechanism for pushing a CSP into child frames
... both the embeddor and embeddee must agree on the policy or it's not embedded
... e.g. doubleclick could set a policy for confinement to audited and contracted sources, and the ad would consent agreement
... implemented in chrome for a while, haven't seen a lot of interest from others
... got input from annevk and found the spec was in an unfinished state after an incomplete refactoring

<johnwilander_> Is the DoubleClick example about nested iframes? I.e. a first-party, a third-party DoubleClick iframe with a nested third-party iframe with the creative?

mkwst: is there interest in this from others in the group? worth getting into shape for a CR, or is it back to the drawing board

mikeoniell: I'm interested in seeing something happen here. I'm using it for privacy enabling functions. Currently CSP only works at the top level
... I like the spec as it is, but I'd ask for ability to specify a default CSP for the top level (maybe feature policy)
... hard for small sites logistically to control every page

<yoav> iclelland: The notice to send to the discourse for spec migrations should look something like https://wicg.github.io/admin/intent-to-migrate.html

mkwst: (answering johnwilander_ above) yes. DC wishes to apply policy to the nested frame containing the creative

<johnwilander_> That sounds reasonable.

lukasz: what is the threat model for this. malvertising?
... I think it will be hard for this to be used: parent will not know what to allow

mkwst: parts of the ad ecosystem wishes they had more control. you're correct in the current world, but they'd like to change this.
... please look at the document, I think it's useful.

<mkwst> annevk: We're violating CORS again here, by setting the `Sec-Required-CSP` header.

mkwst: our initial implementation was bad, but if we enforce the header is a valid CSP policy that mitigates the risk somewhat. but I understand the concern.

<mkwst> annevk: Not violating CORS, but SOP.

<mkwst> ... We set expectations about what headers the client would send.

<mkwst> ... Once we added CORS, we added additional exceptions. Preflights, header values, etc.

<mkwst> ... This kind of header have similar characteristics. Some values are under attacker control.

<mkwst> ... Might be able to trick the server into doing something.

<mkwst> ... Sending them with navigations, which makes them dangerous.

<scribe> scribenick: mkwst

UNKNOWN_SPEAKER: I generally consider addition of this kind of header as an SOP violation.
... We need to draw the line somewhere.
... UA headers shouldn't get a free pass.

dveditz: But this is such a good cause?

annevk: I'm ok with doing it, but we need to document it in order to make servers aware of an ever-expanding list of headers that user agents are sending.

dveditz: Since Chrome has an implementation, have y'all used it in any actual websites?

mkwst: Doubleclick is experimenting with it now.

aaj: Security team isn't.

dveditz: Seems like it would be useful same-origin.

aaj: Could be helpful as a restriction similar to `sandbox`?

dveditz: Maybe origin policy with a default fallback CSP?

aaj: One more thought about Anne's concern: we should document these headers.
... But I'm not super-worried about this.
... Could clash with a trusted header that an application is using, which would suck and be bad.
... Perhaps we could require a common prefix?

annevk: The `Sec-` prefix helps, as that can't be set from the web (XHR, `fetch()`, etc?).

yoav: Other types of request headers?
... Client Hints?

annevk: We do want client hints to be developer controlled.

yoav: Could create a distinction if it helped.
... UA generated vs developer generated?

annevk: Those headers would still fall under the general CORS restrictions, length restrictions, etc.

yoav: Make sure that valid browser values get a pass?

annevk: We'd need to explicitly add those to the CORS-safelisted header list.
... A prefix wouldn't help. Each would need its own parser for valid values.

yoav: We talked about double-verification (before and after Service Worker) for Client Hints.
... Perhaps we could simplify that with a prefix?

annevk: For that, it would be best to think something out, write it down, and then we can discuss.
... For now, use the `Sec-` prefix, and require parsing and serializing. Completely unsanitized is not the way to go.

mikeoneill: Permissions workshop: request that the identity of the server origin that's asking permission be somehow embedded in the permission prompt.
... Useful to declare who you are and why you want a permission when asking for it.

permission API

mikeoneill: Requires adding a `request()` mechanism to the API.
... Right now, you get an origin.
... Users don't understand it.

mkwst: Sites will lie.

mikeoneill: The user agent could record the declaration, which can be checked later. "What did I agree to? Who was that company?"
... Explicit declarations create regulatory risk. Breaking law in jurisdictions.

dveditz: The editors of that spec aren't in this group. We took it over as a chartering favor to Web Platform. Perhaps they should take it back.

<johnwilander_> Websites not only lie in prompts but also threaten the user for full on ransomware attacks.

dveditz: wseltzer will know the details.
... We were rechartering, so expedience.

mkwst: I agree with John. We saw abuse, for example, in `beforeunload` events. Ended up taking away the ability.

<johnwilander_> The middle way might involve a menu of static messages.

johnwilander_: I don't know if iOS had this kind of things.
... Native apps? I don't know the APIs there well enough.
... But some sort of format string style mechanism might be reasonable.

mikeoneill: May or may not be in the prompt. Recorded by the user agent. User van look at it later.

johnwilander_: Apple's not encouraging developers to do more of this, but they first inform the user via the mechanism they're in control over. Messages on the page, etc.
... Then popping up the prompt as a second step.
... User has a better chance of understanding.

weiler: I don't recall specific discussion of the permissions API.
... There were takeaways that lead me to think that the current API is fraught.
... Common thread of trying to avoid asking.
... Interrupting the user experience to ask, might serve useful purpose, delivers a bad experience.
... Current structure isn't great. Anti-pattern. Jumping on users as soon as they arrive on the site.
... I don't think this API is the right API.

<johnwilander_> Yeah, the whole "ask as soon as the user loads the page" is an anti pattern.

mikeoneill: Keen on `revoke()`.

mkwst: Me too!
... Chrome has it behind a flag.

annevk: Not sure we need to go into the details here.
... Worth talking about it here?\

dveditz: Concern about work. If folks are showing up, great. If not, someone else should do the things.

weiler: PING plans to talk about the permissions work early on Friday.

annevk: Conflicts!

weiler: Put it on the survey.

<weiler> please.

Spectre.

aaj: It's exciting!
... And important.
... [Slide:
... How do I limit access to my resources?
... CORB, CORP, Sec-Metadata, SameSite]
... How do I make sure my documents live in their own process?
... COWP ("level 1") / `disown-opener`
... How do we restrict the capabilities of documents with dangerous features?
... Ensure that documents with fine-grained timers can't bypass the SOP
... COWP ("level 2"), X-Bikeshed-Force-Isolate
... ]
...Cross-Origin-Resource-Blocking: https://fetch.spec.whatwg.org/#corb
... Cross-Origin-Resource-Policy: https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header
... Sec-Metadata: https://mikewest.github.io/sec-metadata/
... (I'm super-excited about this)
... SameSite cookies: https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-5.3.7
... Cross-Origin-Window-Policy (levels 1 and 2): https://github.com/whatwg/html/issues/3740
... Back to `Sec-Metadata`:
... We'd make the browser send a request header that includes facts about the way the request was made. Destination (as per Fetch), same-site/cross-site, user-activated.
... Enables servers to make intelligent decisions about the way it responds to requests.
... Mike shipped a prototype, broke sites, and gave us good data!
... Internally at Google, this is a powerful mechanism that we think we can reasonable deploy.
... Requires server-side logic, while other mechnisms are just static headers. Deployability tradeoffs. Etc.

<ericlaw_> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Large-Allocation

annevk: rbyers: General agreement that we need a mechanism to force CORS in able to enable high-res timers and memory measurements and etc.
... Web developers love CORS, let's give them more.

johnwilander: has any thought been put into HSTS supercookies?

<weiler> mkwst: apple's approach is interesting. chrome's needs work, we should talk

<weiler> weiler: should that discussion be here in the WG?

<weiler> mkwst: probably. this was the IETF's, but they closed the WG. (not now, though.)

privacy working group

<weiler> pete snyder: more interested in a CG; low bar to entry

<weiler> mkwst: this space is legally fraught.

<weiler> ... there is a new web advertising BG.

<weiler> ... hence my preference for , if not this group, then a WG.

<weiler> pete: way fwd?

<weiler> mkwst: I'll talk to lawyers at google.

<Mike_O_Neill> +q

<weiler> ... we should write down scope we'd want.

<weiler> ... would be best to do this in public in a standards body.

johnwilander: Cookies (HTTP State Tokens, etc)
... Storage Access API (differences between Safari and Firefox)
... Double-keying generally (caches, HSTS, etc)
... HSTS changes (Safari's shipping supercookie mitigations)
... Private Browsing mode (referrer headers, for example)

weiler: There's a client hints proposed breakout tomorrow.

wanderview: Private browser: Web Platform wanted to reference private browsing.
... Would support other wor.

<ericlaw_> https://gist.github.com/mnot/96440a5ca74fcf328d23#user-data-controls-in-web-browsers

wanderview: We hand-waved around it. "Do whatever you do for storage."

<Mek> https://github.com/w3ctag/private-mode/

<hadleybeeman> https://brave.com/private-mode-is-not-really-private/

<hadleybeeman> I am more concerned that the diversity makes it hard for users to protect themselves.

<hadleybeeman> Secondarily, it might be good to make private browsing mode more aggressive, to protect privacy -- but first, I think helping users to understand what is happening when they turn it on... is useful.

yoav: Ongoing issue around Service Workers and resource timing.
... Both are exposing subresources of `no-cors` CSS requests.
... They've been doing that for 6-7 years.
... We need to make a decision about whether this is worth breaking compat for. Or not?
... It would be nice if annevk was around.

jakearchibald: I'm in favor of not breaking existing sites.
... Reasoning is that the types of resources that are being exposed are things like background images on divs. Already have the way to get the computed style of an element, so that's not actually new.
... Font isn't exposed in computed styles. That's new.
... Also imported stylesheets inside stylesheets.

mkwst: Are redirect targets exposed?

jakearchibald: No.

wanderview: sicking's argument was more or less Jake's.
... Also complicated to spec it correctly.
... Same-/cross-origin nesting of sheets. It's hard.
... So far, no one has stepped up to define how that kind of nesting should work.

<falken> service worker issue is: https://github.com/w3c/ServiceWorker/issues/719

yoav: Yup. Underspecified right now in resource timing.

mkwst: What breaks?

yoav: SW stops intercepting some requests. Breaks offline content.

jakearchibald: Also, this content is all in-process.
... So, Spectre.

annevk: Note that CSS loading is underspecified.
... Current state: you have no idea if it goes through a service worker or not.
... The Fetch integration is not defined.
... CSP doesn't work (in theory) because it's not defined.

jakearchibald: If folks ask "Is it safe to put private data into CSS?", I'd say "No."
... Parent page can read data in weird ways. Create elements until one matches and turns green.
... We don't expose comments. So that's something.

wanderview: Does the CSSWG own CSS loading?

annevk: They haven't wanted to own it in the past.

jakearchibald: It must be down to CSSWG to define this loading, right?
... No SRI either.

mkwst: Didn't tabatkins have a proposal?

annevk: Yes. But it didn't go anywhere.

yoav: We can all agree that it would be great if someone else would specify how this works.

wanderview: That's half. The other half is that much of this data is already exposed via other means.\

annevk: Nocors CSS did leak data in the past. Yahoo Mail, for example.

ericlaw_: Login page for popular site did require the ability to read the content of a stylesheet.

annevk: Chrome exposes stylesheet objects for nocors resources.

jakearchibald: That surprises me.

rbyers: I tried that last night, and rules weren't available. We should compare test cases.

annevk: My main concern is leaking URLs of subresources.

jakearchibald: Fonts, `@import`, might be others.

rbyers: Attacker controls the dom, can construct the dom to match the sheet.

<ericlaw_> https://bugs.chromium.org/p/chromium/issues/detail?id=775525

yoav: Fonts can be concluded from geometry?

jakearchibald: Wouldn't give you the URL.
... If the stylesheet is nocors, but the font is cors, do we care?\

annevk: Slippery slope.

aaj: JavaScript is basically public.

yoav: There's a breakout tomorrow. Let's break out.

- DRAFT -

WebAppSec TPAC F2F

23 Oct 2018

Attendees

Contents