High performance text component
javafx at olifanz.com
Fri Aug 31 02:58:37 PDT 2012
>> : In sample 4, you load a Button. I am not currently in security
>> business, then my example is not as good and realistic as possible
>> (and use no bugs, only features).
>> I will suppose an application using a PasswordField in rich text and
>> allowing plugins for some specific features (country-specific web
>> services) but restricting sensible access from plugins to application
>> with Java policies (not using multiple ClassLoader to avoid bugs due
>> to visibility problems or only by simplicity).
>> * A custom localization contain a replacement of the standard
>> <PasswordField .../> by fully-named
>> <external.package.LoggingPasswordField .../>.
>> * The class "external.package.LoggingPasswordField" is provided by
>> a plugin to the application for adding country-specific features
>> (like web services).
>> Given the FXML is loaded by application, it will be in a domain
>> non-restricted by policies and FXML will load without problem a class
>> from plugin. The pseudo-password field in scenegraph can send
>> password to the web.
> For your application, this is not a concern. A localizer cannot
> reference some class that hasn't been loaded into the system, so it is
> not possible to present a malicious password field, unless your
> application has such a malicious password field. Further, unless you
> are dynamically downloading localization files over the web (from
> either an untrusted source or man-in-the-middle attack), there is no
> vector for malicious FXML injection via localization. Only if you
> actually shipped it in your app.
Excepted if the malicious password field is provided by external code
like a plugin for country-specific web services. With standard Java
security, the plugin would be in restricted zone by policy, not by
class-loading (except OSGi-like application), then will be visible from
standard class loader.
By example, currently Jigsaw use the same classloader for all its
modules. A good security policy will usually intercept insecure calls
from plugin to core application but not from core application to plugins
(like a FXMLLoader in core application loading a class from a plugin).
For me, a usual final user would probably have two potentially insecure
practices but clearly unavoidable: adding untrusted plugin and adding
untrusted localization. My problem is only to put boundaries explicitly
where expected by user.
* All displays coming from plugin need to be explicitly viewed as
coming from plugin, not from core application (by example with a
message like "Plugin x.y.z tell you ..." followed by UI of plugin.
* All data of user, accessed by plugin, need to be in a category
allowed by user for this plugin.
* An unofficial localization can display any stupid messages, images
but can not compromise security of core application.
When I see a localization will be allowed to resolve part of general
scenegraph in global namespace of classes, I see this as something
dangerous, because a bad localization associated with a bad plugin can
bypass my boundaries.
But this is clearly not unmanageable, only something to be cautious
(like concatenating strings for creating SQL queries is not inherently
bad, only something to not use with untrusted strings).
I will only put in my memory to avoid loading FXML from localizations
even if technically possible. I will load some decorated strings from
localization and transform these strings in RichText nodes in my code
(without allowing resolution of absolute names like fully qualified
class names). Most of my rich text usecases are coming from content and
not from localization, then it will not be an important problem.
> We could (and have discussed some day doing it) support RTF / HTML
> importers. So that you could supply the text in any of those forms,
> and we'd convert FXML to a fragment of rich text nodes, or HTML (some
> subset thereof), or RTF. But the root case, that this would be a
> security hole, may be possible but I don't see how it could be a
> reasonable attack vector since we'd turn off all scripting support for
> these FXML fragments.
Adding an importer from RTF / HTML to current API will clearly solve my
concern because you will have an official way (for documentation,
teaching, etc.) to allow localizable rich texts, without resolving
identifiers used in rich text in the global namespace of a classloader
but in a local namespace of RTF / HTML commands.
More information about the openjfx-dev