New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVG- Persistent Cross site Scripting #4949
Comments
|
Comment by @alecpl on 29 Dec 2015 12:37 UTC Hmm... Firefox and Chrome doesn't give me a possibility to open the svg attachment. If I use the mail/get url I can indeed see the alert (in Firefox it says "undefined"). However, I don't see how an attacker could make the use of such URL. |
|
Milestone changed by @alecpl on 29 Dec 2015 12:37 UTC later => 1.1.5 |
|
Comment by akhilreni on 29 Dec 2015 17:09 UTC If a user opens the attachment in a new tab, the xss triggers.
Works like a charm on chrome Version 47.0.2526.106 m windows 8. |
|
Comment by @thomascube on 2 Jan 2016 14:51 UTC Indeed, opening an SVG file directly in the browser can be desired, although opening the attachment URL in Roundcube should force a download. As the SVG document is then loaded from the webmail domain, we probably need to sanitize its contents. A similar approach as for filtering HTML bodies (XML DOM traversal) might be implemented. |
|
Comment by @alecpl on 4 Jan 2016 09:42 UTC There's already some related code in get.inc: I'm not sure we could/should integrate SVG sanitization with it. I suppose we should use For svg we could indeed be more smart and use DOMDocument to remove script tags or convert to jpeg, but not all installations have ImageMagick. |
|
Comment by @alecpl on 7 Jan 2016 08:44 UTC So, the commit fixes only <script>, but there can be also other insecure constructs. As in HTML javascript can be in some attributes (like 'onload'). There can be also insecure code in styles, etc. We could create something similar to rcube_washtml, but... There can be always some insecure construct that we forgot or there can be always a bug in the code. I propose instead to convert svg images to png using ImageMagick. I think that will give as best security. If ImageMagick is not installed we'll print an error to the log and return error code 500. |
|
Comment by @thomascube on 7 Jan 2016 08:55 UTC Replying to alec:
Rendering SVG into an image IMO is a regression for user experience and not my favourite solution. I think we reached a fairly good state with the HTML and CSS sanitisation and the threats coming from SVG are pretty much the same. We should therefore use the same code or logic to do clean SVG documents. |
|
Comment by @alecpl on 9 Jan 2016 17:34 UTC This is tricky, but I started working on integrating SVG support into rcube_washtml. See dev-svg branch. a1fdb20 It's not ready yet. It does not remove all XSS threats, it removes too much (some of my test images look different with and without "washing") and it breaks some existing HTML washing code (failing unit-tests), but maybe it's the way to go. |
|
Status changed by @alecpl on 18 Jan 2016 09:31 UTC new => closed |
roundcube/roundcubemail#4949 (cherry picked from commit 3060ff4)
Reported by akhilreni on 29 Dec 2015 11:46 UTC as Trac ticket #1490625
Hello,
Svg images generally contain css, but more importantly javascript.
The fact that you can execute JavaScript from inside an image file presents an unexpected vector for XSS attacks.
After uploading the following svg file as attachment to an email will execute javascript.
<script type="text/javascript"> alert(document.cookie); </script>Steps to reproduce:
-Compose email
-save the above code as xss.svg
-attach the svg file
-Check the email
-open attachment in new tab
-Xss will be triggered.
Migrated-From: http://trac.roundcube.net/ticket/1490625
The text was updated successfully, but these errors were encountered: