SVG Working Group Teleconference -- 05 Jun 2014

<trackbot> Date: 05 June 2014

<scribe> scribe: Rich

<nikos_> scribenick: richardschwerdtfeger

How SVG and CSP can play nicely together.

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

Resolving the Face to Face Dates for London

<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

- DRAFT -

SVG Working Group Teleconference

05 Jun 2014

Attendees

Contents

How SVG and CSP can play nicely together.

Resolving the Face to Face Dates for London

Summary of Action Items

Scribe.perl diagnostic output