See also: IRC log
<trackbot> Date: 05 June 2014
<scribe> scribe: Rich
<nikos_> scribenick: richardschwerdtfeger
mkwst: SVG poses an interesting
set of questions
... generally speaking security policy is devided into a number
of directives
... these directives control resource types where SVG falls
into the cracks
... may be loaded as an image
... an SVG document can load other images
... if example.com loads an SVG image what should we do with
the resources loaded with that image
krit: Do you want an answer now to your questions?
mkwst: it would be awesome but I
don’t expect them.
... Does the group have questions about common security
policy?
... since you are having a meeting I thought I would crash it
to start the discussion
krit: in the case of loading an
image we don’t load any resources in SVG.
... an SVG image has its own context
mkwst: so one additional
publication. SVG has the ability to control inline style and
script
... if pushes .. down into an SVG document what are the
implications?
... then there are IFrames
krit: IFrames are a different discussion
mkwst: Authors needs to limit the
SVG document
... are there features that are not covered by the current set
of directives.
shepazu: so there are a couple of things. Are you aware of the <use> element
shapazu: use allows you to clone an element in line
shapazue: say you have a circle and a rectangle. define that once. Then you can use that element throughout the document in that it clones the element.
shepazu: SVG allows you to use an
external resource
... people have called this a security issue
... The element being used could include script
... say a have a person icon in document 2
... the person icon could have script
... in any case the use element would allow you to use static
images.
krit: For the use element within
a document, there is no policy yet,
... We don’t define restrictions as of yet.
bhill: it looks like from the integration spec draft you can reference external documents. Can we shoehorn this into image.
krit: we should restrict with CSP
shepazu: we should be true to the
same. We might run into an exception but I don’t anticipate
doing so
... what is the security issue with inline styles and is this
applicable to any CSS or other CSS properties?
bhill: We would inject CSS that could infiltrate data about the web site
mkwst: we could determine whether content was on the page and ping that to an external server
krit: for images we don’t allow any requests
shepazu: this is about fetching external resources across domain
mkwst: fetches is a vehicle for
exfiltration
... the way that a page is constructed is certainly useful to a
hacker
krit: What is the pattern for using selctors to get …
mkwst: if you can inject HTML into the page you can use CSS to make it look like part of the page and direct you to another page. This would make phishing easier
krit: fill, stroke, are properties. So setting these on an SVG image is not a problem.
shepazu: we have things called
presentation attributes. If I can say fill blue in CSS I can
also say fill as an attribute (fill=“blue”) on the element. It
roughly has the same effect.
... so, in that sense SVG does not need CSS to do inline
styles. People would need to manipulate the DOM to provide
these CSS attributes
... when they get to the point to change the DOM this is an
issue
... you can use presentation attributes vs. presenation
attributes. I don’t see this is an issue.
... I am saying that if the style element disabled you could
use presentation attributes vs. CSS properties
bhill: isn’t it hard to avoid to
inject content?
... the thing is you can use selective loading into the
document to exfiltrate data out.
cam: you want to inject content into the style attribute of the element which is more like than injecting content in where you can make any changes you want
mkwst: you can use CSS to modify the look with out content injection.
cam: a hacker can change the style on a given element using an external style sheet.
mkwst: yes
bhill: you can inject a link element.
krit: were you asking for the general use case of SVG or SVG as image?
cam: I want to know what that CSP keyword does.
krit: it is a complex topic. we
svg as a root document, and image, with an iframe. so we have a
number of issues
... you can have an image tag in html content
... a lot of the content created with SVG uses inline
style
... I don’t think that disabling style on SVG images is going
to work
mkwst: what I would like to
evaluate is the risk that SVG images create. They need to not
have access to the content they are embedded and cannot pull in
resources.
... we just need to verify that those 2 are always the case and
and if so I am not particularly worried
krit: that is the case
cam: we need to put this information in (into the SVG Integration spec)
mkwst: what are the capabilties
of SVG when loaded into an ifrrame or an iframe of that same
origin. A content security policy needs to be delivered in
these cases
... a security policy must be in place to cover all the things
SVG can do.
<terri> http://www.w3.org/TR/CSP/#directives
<krit> https://svgwg.org/specs/integration/
mkwst: the common security spec. mentions little about SVG as I know little about it
<mkwst__> https://w3c.github.io/webappsec/specs/content-security-policy/#sec-directives <-- Editor's draft of CSP 1.1 is a more up-to-date resource.
krit: should there a difference with iframe, object, or embed?
mkwst: I don’t know. What are the differences that are relevant?
cam: we don’t know
... the difference with how the document is treated is some
sizing.
mkwst: different directives will dictate will dictated by the resource
cam: gradient, use elements, we
say the external document is loaded as a resource document. In
the future we will say that these disable script
... should individual elements refrence things or the whole
effort we have a policy regarding loading resources
shepazu and krit: we thing we should apply to the whole SVG spec. not individual elements
krit: for resources documents we
had the same policy as images
... some don’t support resources at all
cam: the resource document can’t load scripts or have external resources at all
shepazu: there are 2 different
ways of style. One involves CSS and the other makes use of
attributes
... unlike CSS which has selectors which can change an element.
I don’t see how there can be a security issue with attribute
based styling as they don’t have selectors.
... another nuance of the use element is that if I have 2 SVGs
injected into and HTML document. SVG 1 can use a resource from
SVG2. If Ihave an icon and I inject both SVGs into the page. I
can use an icon from SVG2 into SVG1
... I don’t have to use the same origin. Those resource might
have actual different origins
krit: so it is like one document
shepazu: yes
mkwt: We problaby need an unsafe inline directive for and SVG inline into the page
krit: why image?
mkwt: the other option is that we control it via script given that SVG can control it via script.
shepazu: it is markup not script
cam: I think if your page allows inline SVG somehow the hacker brings in script the script could control the page
mkwt: the hacker could inject SVG where the author was not expecting
terri: a lot of people have broken content filters
cam: people are checking for HTML and are not really looking at SVG which can use script
mkwt: it is easy to inject say a pornographic image
shepazu: how much of this is security vs. defacement
mkwt: this is for protection against defacement as well as script injection. The overarching control is to put hands into the site author so that they are not surprised.
shepazu: I need to talk to you
about annotation
... we certainly have focused on a number of issues around
SVG
... I wrote the SVG integration spec. but I did so without a
reallistic view of security.
krit: we more or less address
issues but have not made major changes for security
... please review the spec and identify issues.
shepazu: don’t take the spec. as
reflective of our opinions or how browsers work currently
... Having you guys review SVG integration would help us in
setting our goals
mkwst: that sounds reasonable. Going forward we should start conversations on the mailing list
ed: On the wiki we should list all the issues that are found. it is easy to get lost in the mail
shepazu: should we do this on the general W3C wiki?
<scribe> ACTION: Doug start a page on the general W3C wiki on security [recorded in http://www.w3.org/2014/06/05-svg-minutes.html#action01]
<trackbot> Created ACTION-3629 - Start a page on the general w3c wiki on security [on Doug Schepers - due 2014-06-12].
ed: most of the discussion should be on the mailing list
cam: it would be good to ask
concrete questions
... if you have questions … does this CSP directive effect
SVG?
mkwst: we are not on www-svg
shepazu: are we talking about this in the context of 1.1?
mkwst: 1.1
<shepazu> https://www.w3.org/wiki/SVG_Security
<mkwst__> Thanks folks, looking forward to future cooperation. :)
cam: we talked about hte dates for London. I will book that in the London office. We did resolve meeting just before graphical web.
<terri> Thanks, that was really interesting from a security perspective!
<heycam> http://www.w3.org/mid/538BBE1F.3040805@mcc.id.au
cam: given that graphical web is
on a Wednesday.
... one was to make Th, Fr, Mo, Tues.
krit: I would prefer starting on Friday
shepazu: starting friday and going saturday and sunday
<krit> cabanier: and krit: would prefer Friday either
cam: I am not sure everyone is
going to the graphical web
... could do the action editing on Saturday
shepazu: are you going to suggest places to stay or are we on our own?
cam: good question
... I can look into special rates
RESOLUTION: London Face to Face: Friday, Saturday, Sunday
ed: Sydney face to face host by Google?
shepazu: webplatform.org is a documentation site
<ed> all: sounds good
<ed> ed: will tell Shane to go ahead with the planning
shepazu: we want the SVG documentation really good for this summer
RESOLUTION: Google hosts Sydney face to face jan/feb
<ed> ACTION: ed to add a wikipage for Sydney F2F (early 2015) - hosted by google, co-located with csswg [recorded in http://www.w3.org/2014/06/05-svg-minutes.html#action02]
<trackbot> Created ACTION-3630 - Add a wikipage for sydney f2f (early 2015) - hosted by google, co-located with csswg [on Erik Dahlström - due 2014-06-12].
shepazu: would anyone want to
hang around for a documentation day after graphical web?
... this would be in London.
... I will take some vacation time after graphical web.
<heycam> I will update the group soon with the London F2F meeting details.
shepazu: I am not sure people involved with graphical web would be interested in documentation
ed: please update the wiki page for the London F2F
shepazu: will do
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) Succeeded: s/ed/krit/ Succeeded: s/ its own content/ its own context/ Succeeded: s/mkwt/bhill/ Succeeded: s/bhill/mkwst/ Succeeded: s/mkwst/bhill/ Succeeded: s/mdwst/mkwst/ Succeeded: s/in/in (into the SVG Integration spec)/ Succeeded: s/id/iframe/ Succeeded: s/chris/krit/ Succeeded: s/krit/ed/ Succeeded: s/Syndy/Sydney/ Found Scribe: Rich Found ScribeNick: richardschwerdtfeger Default Present: BHill, Rich_Schwerdtfeger, cabanier, ed, terri, mkwst__, [IPcaller], heycam, krit, stakagi, nikos_, Doug_Schepers, Tav Present: BHill Rich_Schwerdtfeger cabanier ed terri mkwst__ [IPcaller] heycam krit stakagi nikos_ Doug_Schepers Tav Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Jun/0005.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 05 Jun 2014 Guessing minutes URL: http://www.w3.org/2014/06/05-svg-minutes.html People with action items: doug ed WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]