New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 710910 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security



Sign in to add a comment

CSP does not prevent inline SVG load, leading to cookie injection

Reported by s.h.h.n....@gmail.com, Apr 12 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce the problem:
1.  Go to https://vuln.shhnjk.com/csp_svg.php

What is the expected behavior?
Content-Security-Policy: default-src 'none'; should prevent loading SVG  

What went wrong?
SVG is loaded (because not considered in spec?) therefore it sets cookie using following code.

<svg xmlns='http://www.w3.org/2000/svg'>
<circle r='100'>
</circle>
<foreignObject>
<html xmlns='http://www.w3.org/1999/xhtml'>
<meta http-equiv='Set-Cookie' content='test=value' />
</html>
</foreignObject>
</svg>

Did this work before? N/A 

Chrome version: 57.0.2987.133  Channel: stable
OS Version: OS X 10.12.4
Flash Version:
 
Components: Blink>SecurityFeature>ContentSecurityPolicy
Summary: CSP does not prevent inline SVG load, leading to cookie injection (was: CSP does not prevent SVG to load which leads to arbitrary cookie injection)
This also repros in Firefox 55.0a1.

https://www.w3.org/TR/CSP2/ implies to me that the embedded SVG nodes are permitted but the contents should be restricted by CSP. Since META http-equiv isn't script, it presumably is doesn't demand unsafe-inline permission.

Stepping back a bit, does CSP prevent interpretation of META HTTP-Equiv values elsewhere in the HTML?
Related proposal to add a directive to CSP that controls use of META: https://github.com/w3c/webappsec-csp/issues/112
Cc: mkwst@chromium.org
Mike -- Can you confirm and suggest an owner?
Cc: andypaicu@chromium.org

Comment 6 by est...@chromium.org, Apr 18 2017

Labels: -Restrict-View-SecurityTeam -OS-Mac OS-All
Status: WontFix (was: Unconfirmed)
Since this issue is discussed publicly in https://github.com/w3c/webappsec-csp/issues/112, I'm going to derestrict and WontFix this (for now). Sounds like it should be resolved in the CSP spec before we make any changes in Chrome, other than the metrics gathering that mkwst already did.

Thanks for the report!

Sign in to add a comment