Content-Security-Policy script-src Clarification

[jryoung]

Hi,

With regard to Content-Security-Policy support in SmartClient, can you confirm that SmartClient does not support 'script-src' settings for both 'unsafe-inline' and 'unsafe-eval'? I see here this question was posed referencing 'unsafe-inline', but the answer was given in the context of 'unsafe-eval' via this thread. I just wanted to clarify if both settings are not supported.

Generally, are there any plans to improve support for these settings within SmartClient platform in the future? From what I can surmise, the inline event handlers within SmartClient emitted HTML is one aspect (in relation to 'unsafe-inline') that becomes problematic. Are there any plans to alter this approach to get around this limitation?

Having a number of applications that leverage the SmartClient platform, we have been tasked with improving our security posture within these applications and would like to understand if there are any plans in the works to address this limitation in the platform.

[Isomorphic]

"unsafe-inline" is also completely useless to enable, and supporting it would require the framework to be slower, less flexible and less capable, for no benefit.

These "security" settings were introduced because incompetent JavaScript developers were using eval(), new Function(), etc frivolously, opening themselves up to injection attacks.

Turning on these settings is like closing all the roads because some people can't drive.

We use eval / new Function() for what it was designed for: optimization, browser workarounds, powerful dynamic features like user-defined formulas and web-based development tools, as well as powerful debugging capabilities such as the Developer Console, which allows you to inspect your dynamic application state.

This is not a "limitation". We have absolutely made the right architectural choice here.

Other frameworks that are claiming they are "more secure" for being compatible with these options are not actually "more secure", they are simply far less capable.

If you are having trouble with an internal review of some kind, we have consulting services, where you could bring us in to educate people on effective security policies.

Please bear in mind, we have a very long history of not having any meaningful exploits against our framework - a better record, and longer by far, than any similar company. We know what we're talking about.

[Isomorphic]

To follow up on this, if we were to create an edition of SmartClient which was compatible with these security settings, it would require a long document explaining all of the features that are not supported in this mode, so the result would be a long document explaining:

1. features that are not supported in this configuration, including most of the Developer Console, dynamic formulas, String Methods, various features of the FileLoader, "scriptInclude" transport, Reify/Visual Builder and many other features

2. features that can be expected to run significantly slower, including literally all server contact slowing down measurably

3. bugs we can no longer work around, causing certain memory leaks and issues with accessibility, so applications now need to work around them

If someone really, really wants this, it would require approximately 3 weeks of Feature Sponsorship to create a mode that cripples the framework and document all the ways in which it was crippled.

There would be no gain of any kind, and security would not improve.

However, we do understand that some people have an intractable boss or customer demanding it, so we would go ahead and support this crippled mode if someone absolutely needs it. Just let us know.

[asingla]

We appreciate your response. One counter argument I would like to add that teams use frameworks like smartclient as they don't have resources and/or required skill set around javascript to build on their own. Now using smartclient itself requires writing javascript code. So even if smartclient guarantees that their framework is fully secure, there can be issue with the application code written around smartclient. The whole purpose of CSP headers are to eliminate the possibilities of security vulnerability even if there is some bad code.

Having said that, can you please confirm our understanding based on your response

1) Smartclient does not have in their roadmap to support removing use of unsafe-inline, unsafe-eval. Please confirm.
2) What do you mean by "crippled mode"? Some features will not work? Will it be backward compatible? And how this will work for future upgrades?

Your answers will help us planning our future use of the framework.

[Isomorphic]

We do not have plans to support "unsafe-eval" because it is not meaningfully possible to deliver our product with this setting in place. With the unsafe-eval restriction in place, it would only be possible to deliver a crippled, less capable, slower product, with no possibility of meeting backwards compatibility with the current product.

If a customer came along and was willing to finance the development of a "unsafe-eval" mode of our product, we would agree to do so, and then we could deliver a severely crippled version of SmartClient, as described above.

If you wanted support for "unsafe-inline" without support for "unsafe-eval", that would be easier to support and less crippling; in that mode, the framework would be just slightly slower, and we would only have to document a handful of new limitations (such as no event handlers in canvas.contents).

However, if you are using SmartClient properly, you would not be inserting HTML with inline event handlers from application code, so the argument that it benefits naive developers doesn't really apply.

In order to see a benefit, you would need:

1. an organization that is doing a lot of direct DOM manipulation alongside limited use of SmartClient

2. ... who have developers that are naive about security and have repeatedly introduced security flaws related to DOM insertions

We have few if any such customers; for almost all customers, a mode that supports the "usage-inline" CSP header would just make SmartClient worse without improving security.

But that's why Feature Sponsorship exists: if you are in the above situation, you can use sponsorship to add the work to our roadmap.

-----

As far as the counter-argument that naive developers may need restrictions in place that aren't required for well-vetted framework like SmartClient, there are many approaches to making sure that junior developers do not make security mistakes through unsafe use of code generation:

1. code checking tools like ESLint (and literally dozens of alternatives) can check for violations of rules you apply to application-level JS code

2. "use strict" prevents eval

3. TypeScript & ES6 code transformers can be used for application code, which SmartClient has great support for

4. well-documented best practices, and especially code reviews, are a necessary practice to prevent prevent junior developers from introducing security flaws. You need to be doing this if you care about security at all; it's not specific to CSP headers

None of these approaches require crippling limitations on the frameworks you use. Sorry to state it so starkly, but we need to do so because this is a public discussion: this is absolutely not a valid counter argument, at all. You can prevent junior developers from making security mistakes without crippling the frameworks you rely on.

------

For a final sanity check: all of the world's major banks, defense contractors and financial institutions use SmartClient. We have passed literally dozens of security review from various institutions with serious and well-justified security paranoia.

There is no other vendor that can say this.

If you want a secure solution, you go with SmartClient - period.

If you go with a vendor that supports these CSP headers, odds are, you will run into a real security problem that they did not handle properly, but that we do.

Thus you will achieve exactly the opposite of your stated aim.