<table><tr><td style="">zx2c4 reopened this revision.<br />zx2c4 added a comment.<br />This revision is now accepted and ready to land.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D10188" rel="noreferrer">View Revision</a></tr></table><br /><div><div><p>+ const QUrl url(src);<br />
+ if (url.isLocalFile()) {<br />
+ out.writeAttribute(QStringLiteral("src"), src);<br />
+ } else {<br />
+ //image denied for security reasons! Do not copy the image src here!<br />
+ }</p>

<p>This probably isn't a good idea either, since a remote attacker can<br />
specify any local path, which could have unintended consequences. It's<br />
a nice way, for example, of expanding a remote memory access into a<br />
remote file access (loading file into malloc'd buffers), causing<br />
traffic on network-mapped file paths, or other mischief. Under no<br />
circumstances should a remote user be allowed to supply an arbitrary<br />
local file path.</p>

<p>I'd recommend entirely denying <img> tags, and instead provide<br />
developers with some other API to show photos. I believe this already<br />
exists, in fact.</p>

<p>If you absolutely must have <img> tags, then at least use an inline<br />
data URI, though this of course has its own problems too.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R120 Plasma Workspace</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D10188" rel="noreferrer">https://phabricator.kde.org/D10188</a></div></div><br /><div><strong>To: </strong>davidedmundson, Plasma, fvogt<br /><strong>Cc: </strong>zx2c4, broulik, aacid, fvogt, plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart<br /></div>