If you are running your application in ADF 11g R2 or 12c environment and using facelets - you should double check, if a source code for the facelet pages is not accessible through the URL. There is another security vulnerability in ADF 11g R2, documented here - Alert for ADF Security - JSF 2.0 Vulnerability in ADF 11g R2. Apparently this is a patch from Oracle for JSF 2.0 vulnerability and also there is a manual fix. However neither patch or manual fix are not applied by default, potentially your source code could be exposed for public access. This is why I post it on the blog - for all ADF users to be aware.
I don't have solution for vulnerability described in this post, you should contact Oracle support and ask for a patch. To reproduce this vulnerability is pretty easy - you could remove "faces" from URL and try to access your page (for example main.jsf), source code for the page will be loaded.
Sample application - VulnerabilityTestCase.zip was tested with ADF 11g R2 and 12c runtime.
It doesn't help to set .jsf extension name in web.xml context parameter, as it does for ADF security vulnerability described in the previous post:
When we reference ADF web page with "faces" in the context root, page content is rendered as expected:
However, if you remove "faces" in the context root and try to access main.jsf - instead of returning error, ADF 11g R2 runtime will bring main.jsf page source code (a bit unexpected, right?):
The same with ADF 12c runtime:
I don't have solution for vulnerability described in this post, you should contact Oracle support and ask for a patch. To reproduce this vulnerability is pretty easy - you could remove "faces" from URL and try to access your page (for example main.jsf), source code for the page will be loaded.
Sample application - VulnerabilityTestCase.zip was tested with ADF 11g R2 and 12c runtime.
It doesn't help to set .jsf extension name in web.xml context parameter, as it does for ADF security vulnerability described in the previous post:
When we reference ADF web page with "faces" in the context root, page content is rendered as expected:
However, if you remove "faces" in the context root and try to access main.jsf - instead of returning error, ADF 11g R2 runtime will bring main.jsf page source code (a bit unexpected, right?):
The same with ADF 12c runtime:
Update from Oracle Support: Patch CVE-2013-3827 is available for this issue in October 2013 CPU.
This is not just a R2 or 12c issue. This has been noted for 11g R1 as well. The fix is pretty simple actually. Add a security-constraint in the web.xml for each of the jsf or jspx pages and add a restriction against a security role (e.g. valid-users). That way, whenever you remove the faces from the URL, the page would always redirect to the faces URL if ADF security is enabled.
ReplyDeleteNo, this is different issue. It is reproduced only with Facelets. And Facelets are introduced from 11g R2 only.
ReplyDeleteAndrejus
Did you receive any feedback from Oracle support already?
ReplyDeleteIf I would have a fix, I would post it :) I will test a fix suggested by Anirban and let you know.
ReplyDeleteAndrejus
Normally for JSF applications we will use the following config
ReplyDeleteFaces Servlet
/faces/*
Faces Servlet
*.jsf
However, for ADF 11.1.2.4 *.jsf mapping doesn't work correctly, however, it helps in preventing the source code from being seen.
Hi Anirban,
ReplyDeleteThis vulnerability doesn't seem to be related with ADF Security config, my sample app is already configured with ADF Security. You can check web.xml - there is security constraint defined and valid-users, all default things configured by JDEV :)
As this vulnerability is reproduced only with Facelets, this will be hardly related to ADF Security.
Regards,
Andrejus
Hi Kokwai,
ReplyDeleteAdding one extra mapping for:
Faces Servlet
*.jsf
doesn't help. Vulnerability for JSF page with Facelets source code is still reproduced in my sample app. Could you test your suggestion with my sample app by yourself?
Mapping for /faces/* is added by JDEV by default, but not *.jsf. However, even if I add *.jsf - it still behaves the same. I can access Facelets page source code from URL, when /faces/ is removed.
So, this vulnerability remains unresolved.
Regards,
Andrejus
How is this a security vulnerability? How is this different from viewing the html source for the page in the browser. Viewing the page structure and binding names doesn't give you any private data.
ReplyDeleteIt is a big difference. In HTML you cant see names of methods, expressions, security role mappings, etc.
ReplyDeleteAndrejus