WebAppSec WG Teleconference, Tuesday, 26-Feb-2013

test

<bhill2> hi, jeff

hey

lol

i hope so, zakim

<jimio> (mostly listening in while on mute today, neil & nick from twitter here too)

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0066.html

<bhill2> scribe: Jeff Hodges

<jimio> sorry, I'm on mute

<bhill2> scribenick: jeffh

<jimio> need to leave early (this is jim)

alrightie

joining us: Dave Ross, Microsoft

<bhill2> http://www.surveymonkey.com/s/NXSTXNN

Brad solicits input on how WG is working, via the survey at the above link

webappsec concall in 2 weeks conflicts with ietf HTTP auth WG session at IETF-86 Orlando

hence cancelling webappsec meeting in 2 weeks

Charter update is underway

hopefully done before F2F in April

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

now look at open actions in tracker

ABarth not present

next victim: Brad

will attempt to chip away at his open action items

Dan Veditz: have sent msg on #92

issue #32

they can be closed

#97 and #109 still in todo queue

<bhill2> https://www.w3.org/2011/webappsec/track/actions/open?sort=owner

abarth has arrived

MWest next: #94 believes is done; #102 working on it, lang wrt events, still looking for an example(s) -- events being specified in some 2ndary spec -- tug his sleeve if anyone has any ideas

bhill: ui safety spec may have an example

mwest: attrs are easy, but there's other issues
... #106, has text coming soon; #116 open; #117 ?; #119 done?

above is correct?

<mkwst_> yup

thx

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0052.html

Script-Hash Proposal

"Proposal for script-hash directive in CSP 1.1"

Nicholas Green

n_ ?

<dveditz> question: is script-hash a replacement for script-nonce, or a separate concept/directive?

abarth: is there particular reason chose utf-8

?

what about ?

nick: got input on that, devs said don't do it, they prefer utf-8

abarth: what is the alt you mentioned?

<dveditz> UCS-2

thx

bhill: there's an issue in that utf-8 apparently isn't all that friendly for some existing content out there in asian encodings
... this is for inline script

dveditz: inline script will be in encoding the doc is in

bhill: but doc can change encoding mid-stream -- worry about bugs and perf overhead
... so, if you want ur content to be stable enough to be hashed for sec purposes, need to declare doc encoding at top of doc

ekr: what about hash alg?
... <can't parse>
... collisions seem like a irrelvant (?) threat model here
... prob with sha-1 is it isn't as strong as other choices
... sha-256 (sha-180?) is stronger than sha-1

bhill: we should ref the algs in xml-sec or web-crypto, and we don't have to define 'em -- we just do parsing and such

ekr: am fine with that, but there's still the question wrt agility -- can u use two different(?) ones concurently?

<ekr> what I was suggesting here is that you should be able to have two hash algorithms at once. that allows transitions.

bhill: we should require alg agility, allow same content to be specified with mult hases, but which hashes we support should be defined by ref to another spec most likely web-crypto
... is suggesting that can attach mult hashes via diff algs to one content doc, and so if UA understands at least one of them, can verify it

dveditz: what is UA behavior if encounters a hash it doesn't understand?

nick: hunch is script-hash would take precedence over unsafe-inline
... would have bkwards compat this way

bhill: need text for that

mwest: does each script loaded on page need to match all csp directives that might possibly apply

tanvi: instead of having unsafe-inline, can have nonce-inline/hash-inline, and so server side could have some way to figure out UA capabilities and adapt what it sends

nick/tanvi: the goal is to get the best protection on new browsers and least likelyhood of breaking old browsers; so if have unsafe-inline, ignore it if theres script-hash present

mwest: if both script-hash and script-src are present they have to match?

nick: might make more sense to say if script-hash is present, ignore unsafe-inline (?)

abarth: there's a lot of overlap in use case in script-nonce and script-hash -- should we do one or not other?

tanvi: was thinking about a case where might want both of themn. if page had inline scirpt, may want script-hash, and if you're also sucking script over the net, use script-nonce for that; but most ads now are in iframes and so aren't using script@src, so maybe not a big deal

ekr: script-mac ? like using a fixed key ?

<ekr> jeffh: yeah.

<ekr> So script-mac with a fixed-key is script-hash

<ekr> script-mac with a null algorithm is script-nonce

nick: CDNs are a use case --

dveditz: you're trying to protect against 3d party changes?

nick: no, just want to restrict inline script and style
... we serve some of our static assets off of cdn, and don't want to re-calc nonce for each request
... when told mobile team they need to make their script loaded not inline, they said no cuz of roundtrip

mwest: page and static assets via cdn?

nick: often both

<dveditz> I don’t see the gain of a hash for inline script

<dveditz> (over script-nonce)

mwest: like idea of combining these some way, might be a way to combine them; bundle this up in some way with script-src ?

<ekr> I had assumed that script-hash was mostly for external scripts

<dveditz> I see the use of hashing for content integrity of 3rd party resources, but that seems it could be an “HTML” feature rather than a CSP feature

abarth: use case of main page mostly on cdn is interesting, will think about

<ekr> Note that for third-party resources, collisions are a clear problem

<dveditz> how so?

<dveditz> you mean a 3rd party will swap content with malicious stuff with the same hash?

<ekr> dveditz: yes

bhill: another item is perhaps using the url-safe base64 encoding

abarth: another issue: if u apply the hash to external resources, u can use this to do "identity queries" on resources you otherwise aren't allowed to read

bhill: let's note this down as an issue

<ekr> issue: same-origin policy identity query via script-hash. issue is you do a third party inline script with a known script-hash. if it succeeds, you know that the target was as expected, even though you can't read it

<trackbot> Created ISSUE-44 - Same-origin policy identity query via script-hash. issue is you do a third party inline script with a known script-hash. if it succeeds, you know that the target was as expected, even though you can't read it; please complete additional details at <http://www.w3.org/2011/webappsec/track/issues/44/edit>.

?: perhaps requiring CORS will mitigate this

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0065.html

bhill: Dave Ross comments on UI Security draft

David Ross comments on UI Security draft, re: X-Frame-Options

DaveR: first was wrt framebusting JS -- issue there is ....

bhill: if you have FB code, and then stuff it in a URL the xss filters will clobber FB stuff for u
... some of the interesting issues is whether we consider x-frame-options to be obsoleted by ui safety spec;
... had been assuming one might deploy both for a while, then deprecate x-frame-options;

daver: if x-frame-options is there and ui-safety isn't, then use the former;

<bhill2> action bhill2 to remove obsolete language for XFO in UI Security draft

<trackbot> Created ACTION-122 - Remove obsolete language for XFO in UI Security draft [on Brad Hill - due 2013-03-05].

daver: don't think it makes sense for the doc at this time to explicitly obsolete x-frame-options; maybe in 10 yrs
... doc sez "if u understand safety, you can ignore x-frame-options", but it is sorta contradicted later on in the spec

bhill: that item is specifically for "accessibility" considerations
... that latter stmt specifically gives the accessibility tool author room to work

<bhill2> http://lists.w3.org/Archives/Public/public-webappsec/2013Feb/0062.html

daver: ok, don't have suggestion for alt text on that, so thinks its probably fine

bhill: there's the allow-from stuff

daver: now by using csp we can take advantage of csp infrastruc; still a tad worried about sites emitting huge bloated headers

tanvi: mozilla was thinking the policy-uri directive is one way to address that

bhill: still an open issue whether we want to include that policy-uri in the draft
... this may be use case for that

daver: sitll a little worried that since you /can/ just cut & paste a ton or origins into that header that that's what we'll get.....

bhill: any limits to # of tokens you'll parse in allowed-srcs ?

?: not in FF

<tanvi> ?=imelven

thx

nominal ans: all of virt memory

<tanvi> there is a max header size, not sure what that is

yeah

<tanvi> but if we use policy-uri that is nto an issue

bhill: will get edits into spec
... meeting adjourned -- please take survey !!

<bhill2> thanks for scribing, Jeff!

welcome: )