You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Yasser Zamani <ya...@live.com> on 2017/09/08 21:49:48 UTC

Allowing user to inject his/her specific utility class into OGNL scopes?

Good morning,

If we suppose "is this OGNL access is an attack?" as our test, adding 
packages to exclusions may have false positives (test is positive but 
it's not an attack). Some issues occur in these false positives.

I spotted such issues for 5 users [1], [2], [3], [4] and myself.

I'll research for a cleaner solution but by now, what's your idea about 
importing something like [5] to Struts2. i.e. allowing user to inject 
his/her specific utility class into OGNL scopes when his/her primitive 
info (e.g. a simple String) is not accessible because of our exclusions?

I can work on that and required documentations on site.

[1] https://issues.apache.org/jira/browse/WW-4852
[2] 
https://stackoverflow.com/questions/44291034/struts2-5-10-1-core-jar-missing-xwork2-dispatcher-package
[3] https://www.mail-archive.com/dev@struts.apache.org/msg43017.html
[4] https://www.mail-archive.com/dev@struts.apache.org/msg42277.html
[5] 
https://mail-archives.apache.org/mod_mbox/struts-dev/201707.mbox/%3CDB5PR08MB1062D3E6D3D0C002F87442AE92A50%40DB5PR08MB1062.eurprd08.prod.outlook.com%3E

Re: Allowing user to inject his/her specific utility class into OGNL scopes?

Posted by Lukasz Lenart <lu...@apache.org>.
2017-09-20 12:14 GMT+02:00 Yasser Zamani <ya...@live.com>:
> Thank you. You're right. So I gives it up as I think it's not general
> enough to being imported into Strut's core.

I would say that most of such issues can be handled in a Struts way
(i.e. by defining a method in action and so on), exposing some custom
tools via a context to be usable in JSPs it's a bad design IMHO.


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Allowing user to inject his/her specific utility class into OGNL scopes?

Posted by Yasser Zamani <ya...@live.com>.
Thank you. You're right. So I gives it up as I think it's not general 
enough to being imported into Strut's core.

But about the idea ... could you please follow up this thread at 
security@struts.apache.org. I'll post about the idea and some current 
security issues soon.

Thanks in advance!

On 9/15/2017 10:34 AM, Lukasz Lenart wrote:
> As I'm not fully grasp the idea behind, you can always use
> #application scope (which is basically a ServletContext wrapper).
> There is also ApplicationAware interface to allow actions deal with
> it.
> 
> Another thing would be implementation of ConfigurationProvider which
> can deal with the ServletContext and you can use
> ServletContextAwareConfigurationProvider in this case.
> 
> You can register your custom ConfigurationProvider as below:
> 
>    <filter>
>      <filter-name>struts2</filter-name>
>      <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
>      <init-param>
>        <param-name>configProviders</param-name>
>        <param-value>com.company.MyConfigurationProvider</param-value>
>      </init-param>
>    </filter>
> 
> The flow is as follow:
> - in your ServletContextAwareConfigurationProvider you use
> ServletContext#setAttribute to inject whatever tool you need
> - in actions implementing ApplicationAware you can inject an action
> specific tools/values into #application scope
> - in JSPs you can call #application['myTool'].doStuff
> 
> 
> Regards
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: Allowing user to inject his/her specific utility class into OGNL scopes?

Posted by Lukasz Lenart <lu...@apache.org>.
As I'm not fully grasp the idea behind, you can always use
#application scope (which is basically a ServletContext wrapper).
There is also ApplicationAware interface to allow actions deal with
it.

Another thing would be implementation of ConfigurationProvider which
can deal with the ServletContext and you can use
ServletContextAwareConfigurationProvider in this case.

You can register your custom ConfigurationProvider as below:

  <filter>
    <filter-name>struts2</filter-name>
    <filter-class>org.apache.struts2.dispatcher.filter.StrutsPrepareAndExecuteFilter</filter-class>
    <init-param>
      <param-name>configProviders</param-name>
      <param-value>com.company.MyConfigurationProvider</param-value>
    </init-param>
  </filter>

The flow is as follow:
- in your ServletContextAwareConfigurationProvider you use
ServletContext#setAttribute to inject whatever tool you need
- in actions implementing ApplicationAware you can inject an action
specific tools/values into #application scope
- in JSPs you can call #application['myTool'].doStuff


Regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

2017-09-08 23:49 GMT+02:00 Yasser Zamani <ya...@live.com>:
> Good morning,
>
> If we suppose "is this OGNL access is an attack?" as our test, adding
> packages to exclusions may have false positives (test is positive but
> it's not an attack). Some issues occur in these false positives.
>
> I spotted such issues for 5 users [1], [2], [3], [4] and myself.
>
> I'll research for a cleaner solution but by now, what's your idea about
> importing something like [5] to Struts2. i.e. allowing user to inject
> his/her specific utility class into OGNL scopes when his/her primitive
> info (e.g. a simple String) is not accessible because of our exclusions?
>
> I can work on that and required documentations on site.
>
> [1] https://issues.apache.org/jira/browse/WW-4852
> [2]
> https://stackoverflow.com/questions/44291034/struts2-5-10-1-core-jar-missing-xwork2-dispatcher-package
> [3] https://www.mail-archive.com/dev@struts.apache.org/msg43017.html
> [4] https://www.mail-archive.com/dev@struts.apache.org/msg42277.html
> [5]
> https://mail-archives.apache.org/mod_mbox/struts-dev/201707.mbox/%3CDB5PR08MB1062D3E6D3D0C002F87442AE92A50%40DB5PR08MB1062.eurprd08.prod.outlook.com%3E

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org