W3C

- DRAFT -

Web Application Security Working Group Teleconference

16 Jul 2014

Agenda

See also: IRC log

Attendees

Present
+1.310.597.aaaa, +1.425.391.aabb, +1.949.273.aacc, BHill, tanvi, neilm, gmaone, +1.503.712.aadd, +1.720.897.aaee, glenn, terri, +49.162.102.aaff, mkwst___, freddyb, +1.415.596.aagg, davidwalp, +1.831.246.aahh, dveditz, puhley
Regrets
Chair
bhill2, dveditz
Scribe
Brad Hill, Neil Matatall

Contents


<trackbot> Date: 16 July 2014

<bhill2> thanks, wendy

<bhill2> Meeting: WebAppSec WG Teleconference, 16-Jul-2014

<bhill2> Scribe: Brad Hill

<bhill2> Scribenick: bhill2

<mkwst___> echo echo echo...

<mkwst___> I hear it too, bhill2.

zakim who is making noise?

<mkwst___> Zakim is picky.

<freddyb> sorry

<dveditz> scribenick: neilm

<bhill2> Scribe: Neil Matatall

<bhill2> Scribenick: neilm

<bhill2> agenda http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0070.html

dveditz: no objections to minutes

Mixed Content Spec feedback (Microsoft)

dveditz: microsoft has concerns around video content/xhr mixed content

davidwalp (?): we can begrudgingly move on

(correction: partners willing to move on_)

dveditz: inifinite scroll sites use this a lot

blob origins in MIX and CSP

dveditz: specification for blob has recently changed to include origin. rather than assume it's same origin, we will know where it comes from

mkwst___: csp: maybe push to next version with better integration fetch
... [mix] tied to fetch, content in blobs would have already gone through a check. insecure data couldn't be used to construct the blob

<dveditz> dveditz thinks we could use the blob: origin instead of requiring blob: be an explicit src list

<dveditz> bhill2 is concerned that blob: is not the same as 'self', it's really unsafe eval since it might be constructed

<bhill2> blob is a DOMXSS sink, can be used to pull content out of DOM and turn into script, same as eval

CSP frame-ancestors and unique origins

mkwst___: frame-ancentors, we want to use the location of the document and not the origin for sandboxed frames

<bhill2> I think we *don't* want it to traverse sandboxed frames

dveditz: sandboxed frames might need special treatment (diff from the about: case)

<bhill2> sites would want to use sandboxed frames to host user-content, it shouldn't be able to re-frame other content and mount clickjacking attacks

<tanvi> we are talking about a csp protected document iframed in an iframe sandbox?

mkwst___: can't say: i want this to be framed by certain sites, or anything in a sandbox

dveditz: spec implies, a sandboxed frame is a unique origin and can't be whitelisted (and this is how firefox is implemented?)

<dveditz> ACTION: mkwst to make sure the spec says frame-ancestors uses the origin rather than the URL [recorded in http://www.w3.org/2014/07/16-webappsec-minutes.html#action01]

<trackbot> Created ACTION-184 - Make sure the spec says frame-ancestors uses the origin rather than the url [on Mike West - due 2014-07-23].

<dveditz> tanvi: yes... a csp-protected doc using frame-ancestors framed by an iframe-sandbox with a unique origin

<bhill2> ACTION bhill2 to make sure that frame-ancestors is relative to origin, not url and without path components

<trackbot> Created ACTION-185 - Make sure that frame-ancestors is relative to origin, not url and without path components [on Brad Hill - due 2014-07-23].

[SRI] What should we hash redux

<bhill2> freddyb do you have thoughts on this if you're thinking of implementing SRI on top of SW?

<freddyb> I have some audio input problems, but I just read up on the thread before the call. I agree with devd that the changes to hash seem to address our previous concerns

<freddyb> what do you think, mkwst___?

<dveditz> resolution: wait until we have an implementation without worrying about gzip to discuss further

<freddyb> +1

<freddyb> (sorry about the audio issue)

SRI and CORS

<dveditz> leave issue for later, after we have basic implementations

[MIX] Consider all CORS requests "active"

mkwst___: get us closer to blocking mixed content

<glenn> sounds good, tnx

mkwst___: "blockable mixed content" vs "optionally ..." (in response to glenn's request to stop using "active" vs "passive")

<dveditz> bhill2: is there anything else I need to do to close the meeting?

Summary of Action Items

[NEW] ACTION: mkwst to make sure the spec says frame-ancestors uses the origin rather than the URL [recorded in http://www.w3.org/2014/07/16-webappsec-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.138 (CVS log)
$Date: 2017/02/15 22:32:48 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: Brad Hill
Found ScribeNick: bhill2
Found ScribeNick: neilm
Found Scribe: Neil Matatall
Found ScribeNick: neilm
Scribes: Brad Hill, Neil Matatall
ScribeNicks: bhill2, neilm
Default Present: +1.310.597.aaaa, +1.425.391.aabb, +1.949.273.aacc, BHill, tanvi, neilm, gmaone, +1.503.712.aadd, +1.720.897.aaee, glenn, terri, +49.162.102.aaff, mkwst___, freddyb, +1.415.596.aagg, davidwalp, +1.831.246.aahh, dveditz, puhley
Present: +1.310.597.aaaa +1.425.391.aabb +1.949.273.aacc BHill tanvi neilm gmaone +1.503.712.aadd +1.720.897.aaee glenn terri +49.162.102.aaff mkwst___ freddyb +1.415.596.aagg davidwalp +1.831.246.aahh dveditz puhley
Agenda: http://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0070.html
Found Date: 16 Jul 2014
Guessing minutes URL: http://www.w3.org/2014/07/16-webappsec-minutes.html
People with action items: mkwst

[End of scribe.perl diagnostic output]