[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[ https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17292236#comment-17292236 ] Eric Norman edited comment on SLING-10147 at 2/27/21, 8:50 PM: --- [~cziegeler] To clarify, the FELIX-6390 improvement is only required for the use case where a WebConsoleSecurityProvider service that implements WebConsoleSecurityProvider2 is not registered. Since org.apache.sling/org.apache.sling.extensions.webconsolesecurityprovider/1.2.0 is included since starter version 11 and provides that service I am not certain how many real world use cases would need the FELIX-6390 fix. Do you have some more data about whether existing customers typically use the webconsole with sling without the o.a.s.extensions.webconsolesecurityprovider bundle (or equivalent) deployed? was (Author: enorman): [~cziegeler] To clarify, the FELIX-6390 improvement is only required for the use case where a WebConsoleSecurityProvider service that implements WebConsoleSecurityProvider2 is not registered. Since org.apache.sling/org.apache.sling.extensions.webconsolesecurityprovider/1.2.0 is included since starter version 11 and provides that service I am not certain how many real world use cases would need the FELIX-6390 fix. Do you have some more data about whether existing customers typically use the webconsole without the o.a.s.extensions.webconsolesecurityprovider bundle (or equivalent) deployed? > scripting variables implementation details are exposed to not authorized users > -- > > Key: SLING-10147 > URL: https://issues.apache.org/jira/browse/SLING-10147 > Project: Sling > Issue Type: Bug >Reporter: Eric Norman >Assignee: Eric Norman >Priority: Major > Fix For: Scripting Core 2.3.6 > > Time Spent: 4.5h > Remaining Estimate: 0h > > The ".SLING_availablebindings.json" selector is registered at > /apps/sling/servlet/default and the usage on all resources is not protected > by any security checks. The information returned contains implementation > details that a regular user should not need to know and could be considered > an "information disclosure" vulnerability. > Since this selector appears to only be used by the "Scripting Variables" > webconsole plugin, I would expect that it should require the same security > checking that would be needed to access the webconsole. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[
https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17290010#comment-17290010
]
Julian Sedding edited comment on SLING-10147 at 2/24/21, 3:19 PM:
--
[~enorman] would it be possible to re-implement the default authentication
(i.e. without a {{WebConsoleSecurityProvider}}) as a
{{WebConsoleSecurityProvider}}? This could be the default implementation and
only be registered as a service unless another one is available. If this was
the case it would then be simple to secure all sorts of web-console related
servlets. Granted, the bindings are probably a bit of an edge case. So it may
not be worth the effort.
was (Author: jsedding):
[~enorman] would it be possible to re-implement the default authentication
(i.e. without a {{WebConsoleSecurityProvider) as a
}}{{WebConsoleSecurityProvider}}? This could be the default implementation and
only be registered as a service unless another one is available. If this was
the case it would then be simple to secure all sorts of web-console related
servlets. Granted, the bindings are probably a bit of an edge case. So it may
not be worth the effort.
> scripting variables implementation details are exposed to not authorized users
> --
>
> Key: SLING-10147
> URL: https://issues.apache.org/jira/browse/SLING-10147
> Project: Sling
> Issue Type: Bug
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: Scripting Core 2.3.6
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> The ".SLING_availablebindings.json" selector is registered at
> /apps/sling/servlet/default and the usage on all resources is not protected
> by any security checks. The information returned contains implementation
> details that a regular user should not need to know and could be considered
> an "information disclosure" vulnerability.
> Since this selector appears to only be used by the "Scripting Variables"
> webconsole plugin, I would expect that it should require the same security
> checking that would be needed to access the webconsole.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[
https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287259#comment-17287259
]
Eric Norman edited comment on SLING-10147 at 2/19/21, 5:59 PM:
---
[~bdelacretaz] I am not opposed to such "functional privilege" concepts in
general and I have advocated for such things in the past. But I must point out
that the whole reason for the extra code in that pull request is to make it
independent of optional security concepts. In other words to work when the
org.apache.sling:org.apache.sling.extensions.webconsolesecurityprovider bundle
is not present and the webconsole is protected by the default simple admin
username/password as defined in the "Apache Felix OSGi Management Console"
configuration.
If I am allowed to assume that
org.apache.sling:org.apache.sling.extensions.webconsolesecurityprovider (or
equivalent) is present then the solution would be just a couple lines of code
as I could get a reference to the WebConsoleSecurityProvider service and call
WebConsoleSecurityProvider2#authenticate to check the security in
[SlingBindingsVariablesListJsonServlet|https://github.com/apache/sling-org-apache-sling-scripting-core/blob/master/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java]
Can I require that the optional WebConsoleSecurityProvider be present to allow
access? Is that any different than assuming that the resource tree is writable
and capable of defining a {{/system/sling/permissions/webconsole/view}}
resource?
was (Author: enorman):
[~bdelacretaz] I am not opposed to such "functional privilege" concepts in
general and I have advocated for such things in the past. But I must point out
that the whole reason for the extra code in that pull request is to make it
independent of optional security concepts. In other words to work when the
org.apache.sling:org.apache.sling.extensions.webconsolesecurityprovider bundle
is not present and the webconsole is protected by the default simple admin
username/password as defined in the "Apache Felix OSGi Management Console"
configuration.
If I am allowed to assume that
org.apache.sling:org.apache.sling.extensions.webconsolesecurityprovider (or
equivalent) is present then the solution would be just a couple lines of code
as I could get a reference to the WebConsoleSecurityProvider service and call
WebConsoleSecurityProvider2#authenticate to check the security in
[SlingBindingsVariablesListJsonServlet|https://github.com/apache/sling-org-apache-sling-scripting-core/blob/master/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java]
Can I require that the optional WebConsoleSecurityProvider be present to allow
access? Is that any different that assuming that the resource tree is writable
and capable of defining a {{/system/sling/permissions/webconsole/view}}
resource?
> scripting variables implementation details are exposed to not authorized users
> --
>
> Key: SLING-10147
> URL: https://issues.apache.org/jira/browse/SLING-10147
> Project: Sling
> Issue Type: Bug
>Reporter: Eric Norman
>Priority: Major
> Fix For: Scripting Core 2.3.6
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> The ".SLING_availablebindings.json" selector is registered at
> /apps/sling/servlet/default and the usage on all resources is not protected
> by any security checks. The information returned contains implementation
> details that a regular user should not need to know and could be considered
> an "information disclosure" vulnerability.
> Since this selector appears to only be used by the "Scripting Variables"
> webconsole plugin, I would expect that it should require the same security
> checking that would be needed to access the webconsole.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[ https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286185#comment-17286185 ] Eric Norman edited comment on SLING-10147 at 2/17/21, 11:04 PM: [~kwin] Yes, that was my conclusion as well. My first thought was the simple solution of using a reference to a WebConsoleSecurityProvider service that implements the WebConsoleSecurityProvider2 interface and call WebConsoleSecurityProvider2#authenticate to do the validate the security credentials. That works ok when that service exists, but if there is no such service then the security checks become more complex and rely on the some internal implementation details... How would you feel about changing the request flow a bit, so the all the calls from the "Scripting Variables" form are POSTed to the ScriptingVariablesConsolePlugin servlet (which would flow though OsgiManagerHttpContext#handleSecurity) that sets some value as a request attribute and then forwards as a GET request for processing the response? Then changes can be made to ensure that any request to the SlingBindingsVariablesListJsonServlet that arrives without the expected request attribute is rejected and 404 is returned (or use OptingServlet)? was (Author: enorman): [~kwin] Yes, that was my conclusion as well. My first thought was the simple solution of using a reference to a WebConsoleSecurityProvider service that implements the WebConsoleSecurityProvider2 interface and call WebConsoleSecurityProvider2#authenticate to do the validate the security credentials. That works ok when that service exists, but if there is no such service then the security checks become more complex and rely on the some internal implementation details... How would you feel about changing the request flow a bit, so the all the calls from the "Scripting Variables" form are POSTed to the ScriptEngineConsolePlugin servlet (which would flow though OsgiManagerHttpContext#handleSecurity) that sets some value as a request attribute and then forwards as a GET request for processing the response? Then changes can be made to ensure that any request to the SlingBindingsVariablesListJsonServlet that arrives without the expected request attribute is rejected and 404 is returned (or use OptingServlet)? > scripting variables implementation details are exposed to not authorized users > -- > > Key: SLING-10147 > URL: https://issues.apache.org/jira/browse/SLING-10147 > Project: Sling > Issue Type: Bug >Reporter: Eric Norman >Priority: Major > Fix For: Scripting Core 2.3.6 > > > The ".SLING_availablebindings.json" selector is registered at > /apps/sling/servlet/default and the usage on all resources is not protected > by any security checks. The information returned contains implementation > details that a regular user should not need to know and could be considered > an "information disclosure" vulnerability. > Since this selector appears to only be used by the "Scripting Variables" > webconsole plugin, I would expect that it should require the same security > checking that would be needed to access the webconsole. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[ https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286185#comment-17286185 ] Eric Norman edited comment on SLING-10147 at 2/17/21, 10:44 PM: [~kwin] Yes, that was my conclusion as well. My first thought was the simple solution of using a reference to a WebConsoleSecurityProvider service that implements the WebConsoleSecurityProvider2 interface and call WebConsoleSecurityProvider2#authenticate to do the validate the security credentials. That works ok when that service exists, but if there is no such service then the security checks become more complex and rely on the some internal implementation details... How would you feel about changing the request flow a bit, so the all the calls from the "Scripting Variables" form are POSTed to the ScriptEngineConsolePlugin servlet (which would flow though OsgiManagerHttpContext#handleSecurity) that sets some value as a request attribute and then forwards as a GET request for processing the response? Then changes can be made to ensure that any request to the SlingBindingsVariablesListJsonServlet that arrives without the expected request attribute is rejected and 404 is returned (or use OptingServlet)? was (Author: enorman): [~kwin] Yes, that was my conclusion as well. My first thought was the simple solution of using a reference to a WebConsoleSecurityProvider service that implements the WebConsoleSecurityProvider2 interface and call WebConsoleSecurityProvider2#authenticate to do the validate the security credentials. That works ok when that service exists, but if there is no such service then the security checks become more complex and rely on the some internal implementation details... How would you feel about changing the request flow a bit, so the all the calls from the "Scripting Variables" form are POSTed to the ScriptEngineConsolePlugin servlet (which would flow though OsgiManagerHttpContext#handleSecurity) that sets some value as a request attribute and then forwards as a GET request for processing the response? Then changes can be made to ensure that any request to the SlingBindingsVariablesListJsonServlet that arrives without the expected request attribute is rejected and 404 is returned? > scripting variables implementation details are exposed to not authorized users > -- > > Key: SLING-10147 > URL: https://issues.apache.org/jira/browse/SLING-10147 > Project: Sling > Issue Type: Bug >Reporter: Eric Norman >Priority: Major > Fix For: Scripting Core 2.3.6 > > > The ".SLING_availablebindings.json" selector is registered at > /apps/sling/servlet/default and the usage on all resources is not protected > by any security checks. The information returned contains implementation > details that a regular user should not need to know and could be considered > an "information disclosure" vulnerability. > Since this selector appears to only be used by the "Scripting Variables" > webconsole plugin, I would expect that it should require the same security > checking that would be needed to access the webconsole. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (SLING-10147) scripting variables implementation details are exposed to not authorized users
[ https://issues.apache.org/jira/browse/SLING-10147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286151#comment-17286151 ] Konrad Windszus edited comment on SLING-10147 at 2/17/21, 9:31 PM: --- See the discussion at SLING-3543. Exposing the bindings requires a real Sling Servlet Request, therefore this generic servlet binding. Doing the same kind of access check requires probably a dependency on the WebConsoleSecurityProvider service. But IMHO that service is optional (even with Sling) so it must also work without it. Maybe reusing the OsgiManagerHttpContext is an option (https://github.com/apache/felix-dev/blob/e8fbf5bae0b736e187f603ae05d5b2ebeafb7973/webconsole/src/main/java/org/apache/felix/webconsole/internal/servlet/OsgiManager.java#L961) was (Author: kwin): See the discussion at SLING-3543. Exposing the bindings requires a real Sling Servlet Request, therefore this generic servlet binding. Doing the same kind of access check requires probably a dependency on the WebConsoleSecurityProvider service. But IMHO that service is optional (even with Sling) so it must also work without it. > scripting variables implementation details are exposed to not authorized users > -- > > Key: SLING-10147 > URL: https://issues.apache.org/jira/browse/SLING-10147 > Project: Sling > Issue Type: Bug >Reporter: Eric Norman >Priority: Major > Fix For: Scripting Core 2.3.6 > > > The ".SLING_availablebindings.json" selector is registered at > /apps/sling/servlet/default and the usage on all resources is not protected > by any security checks. The information returned contains implementation > details that a regular user should not need to know and could be considered > an "information disclosure" vulnerability. > Since this selector appears to only be used by the "Scripting Variables" > webconsole plugin, I would expect that it should require the same security > checking that would be needed to access the webconsole. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
