Re: Minutes: June 5, 2014 SVG Working Group Meeting

On 06/06/14 00:06, Richard Schwerdtfeger wrote:
> http://www.w3.org/2014/06/05-svg-minutes.html

The resolution for the London F2F dates should be "Friday, Saturday, 
Monday, Tuesday" rather than "Friday, Saturday, Sunday".



Text contents of the minutes for tracker to ingest:


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

05 Jun 2014

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0005.html

    See also: [3]IRC log

       [3] http://www.w3.org/2014/06/05-svg-irc

Attendees

    Present
           BHill, Rich_Schwerdtfeger, cabanier, ed, terri, mkwst__,
           [IPcaller], heycam, krit, stakagi, nikos_,
           Doug_Schepers, Tav

    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Rich

Contents

      * [4]Topics
          1. [5]How SVG and CSP can play nicely together.
          2. [6]Resolving the Face to Face Dates for London
      * [7]Summary of Action Items
      __________________________________________________________

    <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> [8]http://www.w3.org/TR/CSP/#directives

       [8] http://www.w3.org/TR/CSP/#directives

    <krit> [9]https://svgwg.org/specs/integration/

       [9] https://svgwg.org/specs/integration/

    mkwst: the common security spec. mentions little about SVG as I
    know little about it

    <mkwst__>
    [10]https://w3c.github.io/webappsec/specs/content-security-poli
    cy/#sec-directives <-- Editor's draft of CSP 1.1 is a more
    up-to-date resource.

      [10] 
https://w3c.github.io/webappsec/specs/content-security-policy/#sec-directives

    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
    [11]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> [12]https://www.w3.org/wiki/SVG_Security

      [12] 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> [13]http://www.w3.org/mid/538BBE1F.3040805@mcc.id.au

      [13] 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
    [14]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

Summary of Action Items

    [NEW] ACTION: Doug start a page on the general W3C wiki on
    security [recorded in
    [15]http://www.w3.org/2014/06/05-svg-minutes.html#action01]
    [NEW] ACTION: ed to add a wikipage for Sydney F2F (early 2015)
    - hosted by google, co-located with csswg [recorded in
    [16]http://www.w3.org/2014/06/05-svg-minutes.html#action02]

    [End of minutes]

Received on Friday, 6 June 2014 00:21:57 UTC