jsr372-experts@javaserverfaces-spec-public.java.net

[jsr372-experts] Re: [1359-views] DISCUSSION

From: arjan tijms <arjan.tijms_at_gmail.com>
Date: Thu, 26 Feb 2015 12:29:39 +0100

Hi,

On Thu, Feb 26, 2015 at 11:06 AM, Frank Caputo <frank_at_frankcaputo.de> wrote:
>> AT> The first is that in the default configuration JSF now has a *source
>> AT> code exposure vulnerability*. […]
>
> This was also discussed in 2.2 and we decided to not care about this.

I personally think it's a vulnerability that should be taken seriously.

Source code of proprietary (closed source) products can contain all
kinds of things that the one operating the site may not want to
expose. It's closed source for a reason after all. I did some research
here, including for the companies I was working for, and I found
various things that indeed should not have been exposed. This included
mildly serious things such as comments about competitors that perhaps
weren't too flattering, to really serious things such as credentials
being shown.

In general it provides an attack surface of which many JSF users are
clearly not aware off. I strongly feel JSF should be safe by default,
and not only after the user fiddled with many moving parts.

>Currently ViewResources in Mojarra don’t expose the input stream (which i’d like to see). It is easy to hide facelets.
>
>> AT> The second problem is that in Facelets top level views, includes,
>> AT> templates, etc all have the same extension; .xhtml. The runtime cannot
>> AT> automatically make a distinction between what are top level views [...]
>>
>> Strictly speaking, these two items are different aspects of the same
>> concern.
>
> See above.

If with "See above" you mean "not care about this", then I obviously
don't agree ;)

For extensionless mapping it's kinda important to know which things
are views, and which things are not views. It's not so nice to just
randomly map the FacesServlet to every *.xhtml file the runtime
encounters. Security aside, you just don't want to have
http://myhost.net/includes/dataForm resolve to anything if
/includes/dataform is not a top-level view.

In general, having a clear idea of what are top-level views and what
are not is a powerful tool that extension libraries can take advantage
of for all kinds of things.

I do have to stress that the proposed /views folder is -an- enabler,
but I'm of course open to explore other options to reach the same goal
(prevent source code exposure and determine if a Facelet is a
top-level view or not).

Kind regards,
Arjan Tijms




>
>> One other aspect not mentioned is alignment with the MVC spec.
>
> This one is the only valid one for me. Unfortunately I was really busy the last months and didn’t follow the MVC discussions very well. I’ll take a deeper look into this.
>
> @Manfred, can you explain this a little bit?
>
> Ciao Frank