Summary: | mail viewer loads external fonts even with external refs disabled | ||
---|---|---|---|
Product: | [Applications] kmail2 | Reporter: | Timo Weingärtner <timo> |
Component: | UI | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | grave | CC: | montel |
Priority: | NOR | ||
Version: | 5.15.3 | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/pim/messagelib/commit/f8557851f5e43f991aaeecd5bcbb9597d65b2005 | Version Fixed In: | 5.16.3 |
Description
Timo Weingärtner
2021-01-06 11:08:34 UTC
Git commit f8557851f5e43f991aaeecd5bcbb9597d65b2005 by Laurent Montel. Committed on 03/02/2021 at 06:36. Pushed by mlaurent into branch 'release/20.12'. Fix Bug 431218 - mail viewer loads external fonts even with external refs disabled FIXED-IN: 5.16.3 M +2 -0 messageviewer/src/viewer/webengine/loadexternalreferencesurlinterceptor/loadexternalreferencesurlinterceptor.cpp https://invent.kde.org/pim/messagelib/commit/f8557851f5e43f991aaeecd5bcbb9597d65b2005 I created a patch but I can't be sure. Could you send me an test case for verifying it please ? thanks I sent you a test case in private mail. When reading your patch and the surrounding code it looks like only some (images, now also fonts) request types are blacklisted. What about external style sheets or other types that might grow in HTML-land? Are there any external requests you think should be allowed? Regarding URL schemes: why is file:// allowed? I could think of some social engineering attacks that might work by including files from the victims computer. I would read "external request" as external to the e-mail in question. To me the function could be as simple as: ----8<----8<---- bool LoadExternalReferencesUrlInterceptor::interceptRequest(QWebEngineUrlRequestInfo &info) { if (mAllowLoadExternalReference) { return false; } const QString scheme = info.requestUrl().scheme(); if (scheme == QLatin1String("data") || scheme == QLatin1String("cid")) { return false; } return true; } ----8<----8<---- (In reply to Timo Weingärtner from comment #3) > I sent you a test case in private mail. Yep thanks. I will look at it. > When reading your patch and the surrounding code it looks like only some > (images, now also fonts) request types are blacklisted. What about external > style sheets or other types that might grow in HTML-land? Are there any > external requests you think should be allowed? see "BlockExternalResourcesUrlInterceptor" too but indeed I need to block "style sheets" too. > > Regarding URL schemes: why is file:// allowed? I could think of some social > engineering attacks that might work by including files from the victims > computer. I would read "external request" as external to the e-mail in > question. Because we use file:// for resources too (as loading html template/ local image etc.) => normal. > > To me the function could be as simple as: > > ----8<----8<---- > bool > LoadExternalReferencesUrlInterceptor:: > interceptRequest(QWebEngineUrlRequestInfo &info) > { > if (mAllowLoadExternalReference) { > return false; > } > > const QString scheme = info.requestUrl().scheme(); > if (scheme == QLatin1String("data") > || scheme == QLatin1String("cid")) { > return false; > } > > return true; > } nope :) as we want to be able to load image from loacl etc :) > ----8<----8<---- Why should an email be able to load images from my home directory? What is the use case for loading images from file:// ? (In reply to Timo Weingärtner from comment #5) > Why should an email be able to load images from my home directory? > > What is the use case for loading images from file:// ? For example avatar support. We load html template too. |