High performance text component

[Richard Bair]

> Technically it is perfectly possible, but knowing that adding a localization can change instantiated components in scenegraph (then behaviour [1]) is clearly worrisome for security.

Yes, we've had some thought on this (as you can imagine security is on our mind today). The one thing we must do, of course, is to disable any and all scripting in these fragments. No Java code, no JavaScript code, nothing.

> [1]: 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.

Suppose the application asks a user for input, and then puts that input as display to a Label. In this case, the hacker using the application can feed some FXML to the Label. However he can't actually do anything with it, since he cannot insert any scripting logic. So although he could display a button or password field instead of "Hello Richard" he gets "Hello <MyButton>" or whatnot. But besides the novelty, what has he accomplished? 

Without scripting code, he can't modify the structure of the scene graph elsewhere. Nor can he send any keystrokes to a web server. Without scripting, it is only good for display.

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.

Cheers
Richard