Web Application Security Working Group Teleconference -- 12 Jan 2015

<trackbot> Date: 12 January 2015

<bhill2_> Meeting: WebAppSec WG Teleconference 12-Jan-2015

<bhill2_> Scribenick: deian

<bhill2_> jww will dial in after 12:30

Minutes Approval

first topic: minutes approval

<bhill2_> http://www.w3.org/2014/12/15-webappsec-minutes.html

<bhill2_> minutes approved by unanimous consent

bhill2_: no objections, approved
... TOPIC: Agenda Bashing

Agenda Bashing

wseltzer: thanks!

dveditz: being able to set an attribute that says don't load MIX content in subresources. is that too new of an idea? is it too late to get it in v1?

mkwst: why don't we add that to the MIX section

dveditz: a version made it into editor draft, we shoudl talk about it

bhill2_: sounds good
... any other things for agenda bashing?

Ask your AC reps to indicate support for the charter.

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0236.html

bhill2_: approved by w3c, call was sent out to all commitee reps to indicate support/concerns.
... contact your AC rep and encourage them to vote/indicate support so we can get that wrapped up and being on our new deliverables

Microsoft's LC comments on MIX?

bhill2_: david you asked that we delay moving to recommendation

david: (DWalp) will send email to update on microsoft's status

<mkwst> https://w3c.github.io/webappsec/specs/mixedcontent/#strict-checking

<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0095.html

dveditz: link is to spec. disussion started in mid december (link above)
... mkwst said that its not somethign we should add to CR since its a new feature. it's an interesting features, but implementers are asking whether they need to implement it. we should take a full process to look at this feature

bhill2_: we should put this into experimental

mkwst: if people think we should take more time, we should make sure not to put it in CR draft.
... this is relatively small feature. implimentation is faily trivial. I'd like to try to have it in

dveditz: other option is to go back to LC and add it there

DWalp: microsoft will make replies to comments we put out

bhill2_: we don't have to do formal LC, but we don't have to do it this way if we find that it can be added to CR and marked as experimental (couldn't hear that?)
... there is some precedence for it especially given its similarlity to sandboxing turning off scripting.
... its probably not any worse than sandboxing scripting

<mkwst> https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0128.html is that thread.

dveditz: did the attribute version of this go away?

mkwst: in the ED it sets the flag and is inherited down
... ...hard to hear.. but says we shold go back to list on this

dveditz: we haven't had any time to look at implications of implemenation. seems like a fine idea, but we want to make sure that we can accomplish the spec if it makes it in
... although our arch is different from chrome, happy to hear that you didn't have any trouble implementing

Objection to MIX by the Director

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0002.html

<wseltzer> [not in his capacity as director, but as a concerned individual]

bhill2_: tim berners less commented on MIX. had concern that there are lots collections of open data on web and it's important that web apps access this
... spawened large discussion thread. no updates since bhill2_'s last comments. will find out if there is objection when moving to CR

wseltzer: at the moment he is not formally objecting as director, but as web developer of long standing

bhill2_: anyone know if there are subject matter experts on open data?
... first data point didn't event set CORS, so MIX wouldn't break it. need expert on this

mkwst: we can assume that the # served over HTTPS is low

dveditz: more concerned about them using CORS so that they are sharable

bhill2_: if they all have to make updates to enable CORS anyway, there is less corcerned to ask them to enable HTTPS
... but if they're already widely available today, then this is a different issue

wseltzer: as a first point of outreach, will reach out to w3c groups on open data

<wseltzer> ACTION: wseltzer to ask open data/linked data groups for info on data publishing for use in secure context [recorded in http://www.w3.org/2015/01/12-webappsec-minutes.html#action01]

<trackbot> Created ACTION-209 - Ask open data/linked data groups for info on data publishing for use in secure context [on Wendy Seltzer - due 2015-01-19].

bhill2_: other suggestion is to be mroe agressive to update HTTP links to HTTPS that would otherwise be broken by MIX

tanvi: how do we know what the HTTPS version of the site is

mkwst: intead of blocking an HTTP link to a script preference, you would attempt to load it over HTTP. if it loads, then you're good, but if it blocks it would've blocked anyway

bhill2_: the concerned came from W3C pages. Can't find all the absolute links. If we're talking about removing breakages from moving to HTTPS, can we make this easier

tanvi: I'm fine with doing this, but in the past we've gotten feedback that you can't just assume that the HTTPS is the semantic equivalent

mkwst: HTTPS everywhere extensions has more complicated ruleset - there are cases where HTTPS is on different origin

dveditz: we need to think about how this interacts with redirects. E.g. case is forbes where HTTPS redirects. Yet not following redirects can break

bhill2_: anybody in group have bigger dataset that we can use to look into this further

mkwst: will ask

Accessible content security indicators

bhill2_: didn't link to this. need indication if we're going to switch from SHOULD to MUST

mkwst: in blink we can add a layout pass
... not sure how we would write a W3C spec

dveditz: same for mozilla
... chrome can get at data, but its not web visible

bhill2_: there are other browsers that don't have accesibility features (e.g., mobile). they should, but don't always

dveditz: will look into getting more info fom accessibilty people

mkwst: there are some suggestion on how to do it in chromium

CSP whitelisting and geotargeting of domains

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0108.html

bhill2_: there is concern that there are sites that are trying to apply CSP, but oftentimes users get redirected according to geolocation to entirely different TLDs and this tends to break CSP

dveditz: problem for anyone except google and amazon?

have seen it on CNN

mkwest: I think we will need to find a workaround for this
... hard to hear mkwest.. dveditz: this is not safe

CSP 'self' in sandboxed contexts

bhill2_: need to workound this and continue discussion on list

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0104.html

jww: introduction of another origin concept seems qustionable. had same concern

dveditz: fallback case URL seems like its trying to get at the same value we're trying to use in practice for 'self'

mkwst: do we respect document.domain in this case? if we do why?

dveditz: its evil, ignore where possible
... we don't use origins for base fallback
... we do in some cases, like about:blank, but not sandbox frames
... in sadbox the origin differes, concepts introduced for this purpose
... sandbox is under-specified in terms of effictive origin

jww: we introduced a fundamental incompatability. two mechanisms that break eachother.

mkwst: if I don't know if I'm going to be sandboxed the sandbox is likely to break my page regardless

jww: if we get to the world where CSP is used everywhere then sandboxed everything will be broken

mkwst: if I do know if I wil sandboxed, I will design it so that it doesn't break
... intuition is that I'm more likely to sandbox my own code vs. third-party

bhill2_: self is a single token that is useful for a simple site policy. makes it a lot harder to apply CSP if we expand (?)
... no consensus on this, bring it back to list

<freddyb> uh

*painful noises*

Remove the anchor element from v1 of SRI?

<bhill2_> https://github.com/w3c/webappsec/pull/143#issuecomment-69484590

bhill2_: discusses mostly as github issue
... did not reach a definitive conclusion at TPAC
... we thought that some of the most useful cases are download sides that point to HTTPS resources from HTTP sites

freddyb: my take it just remove it for v1

jww: there were some corner cases, seems like great thing to work for v2

Set default media types for SRI?

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0099.html

bhill2_: won't make it to CR is neither Chome nor FF do it, let's punt to v2
... mkwst and jww didn't think that this was a great idea. anyone think that this is a good idea?

francois: I think that the comments were good, no longer think that it's a great idea.

bhill2_: ok, giving it up then

Glenn Adams's bugs in Bugzilla. Move to Github?

<bhill2_> https://www.w3.org/Bugs/Public/buglist.cgi?component=Subresource%20Integrity&product=WebAppsSec&resolution

propose to just move them

<bhill2_> ACTION bhill2 to move SRI bugs in bugzilla to github

<trackbot> Created ACTION-210 - Move sri bugs in bugzilla to github [on Brad Hill - due 2015-01-19].

Unsupported hashes / hash agility

<bhill2_> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0014.html

bhill2_: how to deal with unsupported hashes and hash agility. two cases: metadata okay, but algorithm not trusted

other case is where old browser hasn't seen this

bhill2_: state on list: no resolution/consensus. do editors have prefered appraoch.

francois: no conclusion yet

or was that freddyb ?

<freddyb> that was me-^ :)

sorry: )

<freddyb> np

dveditz: this somewhat discourages adoption.

mkwst: no one is thinking about agility
... why does it discourage adoption?

<freddyb> .. mkwst earlier said he'd prefer fail-close because its easier

dveditz: because sites will break in middle-old browsers if we invent a new hash later and people start using it
... right now we have distinction between browsers that do not support it at all and those that do. the former will ignore, the latter will check hashes

mkwst: if you are using the integrity attribute then you are expressing intent about integrity of resource. if broser cannot check, it should not load the resource
... I think developers should use multiple hashs
... missed a few things, sorry still hard to hear mkwst...

<mkwst> deian: sorry. :(

dveditz: don't trust the security of this so much that I care if it fail-open

mkwst: if it fails-open what's the point?

jww: difference between developer bug (choosing insecure hash) vs. failing to load resource should be distinguished

<wseltzer> they chose an insecure hash, so the property they thought was guaranteed isn't

bhill2_: likelyhood of finding exploits due to collision is small. even if security of sha256 is weakened by 1/2, we're still providing somewhat meaningful security

<francois> to help determine whether or not it will impact adoption, should we ask github (as a very early adopter of sri) what they think about failing open v. closed?

<wseltzer> +1 to failing closed

bhill2_: agreed, take this as action. people with strong opinions will prefer failing closed

dveditz: failing closed is fine

<bhill2_> ACTION bhill2 to ask GitHub if they prefer fail open / closed on unknown hashes

<trackbot> Created ACTION-211 - Ask github if they prefer fail open / closed on unknown hashes [on Brad Hill - due 2015-01-19].

francois: fine with failing closed but not if it impacts adoption significantly.

dveditz: the one nice thing about failing closed: if one typos sha256 and things fail-close, they'll fix it.

since they find out right away vs. fail-open

<francois> good point, that's much more reliable than relying on devtools warnings

<freddyb> fair point.

jww: if two UAs come to diff conclusion of security of different hash functions
... you might not know that it breaks on different UA
... (in favor of fail-open)

dveditz: you need to test on mulple UAs anyway

<tanvi> or maybe we should try and coordinate deprecation of hash algorithms

<tanvi> to avoid that issue

tanvi: yep :)

<freddyb> UA-1 allows only hash-1 and UA-2 allows only hash-2, you can still list both since they are combined with a logical OR, right?

<freddyb> tanvi: we can happily assign this to the "naming things with hashing" RFC ;-P

<tanvi> what's going on on the 26th?

<freddyb> tanvi: owasp appsec cali

webappsec california, may propose meeting at least for drinks

<wseltzer> https://2015.appseccalifornia.org/ ?

<tanvi> thanks

<dveditz> wseltzer: yes

- DRAFT -

Web Application Security Working Group Teleconference

12 Jan 2015

Attendees

Contents