Re: Url rewriting of .action to .jsp
Am 23.09.2013 20:32, schrieb Lukasz Lenart: 2013/9/23 Paweł Wielgus : Hi all, I'm using DMI to call "input" method extensively, almost in every Edit*Action. I call it with ParamsPrepareParams stack. I fully understand that allowing DMI is a security problem. But maybe some kind of balance could be achevied. White listing with annotations would not be bad for me also maybe letting call only input (or similar) method by default would not cause to much of a security problem? I'm not saying that i will drop S2 if DMI will be disabled, but sure it will make me rewrite all my edit actions. There is "strict dmi" [1] but I doubt that anybody is using it ;-) Anyway, doing some improvement in that area is better than removing DMI at all ;-) Maybe we should switch to strict dmi by default - e.g "execute, input, edit, submit, form" are the only allowed methods to be called via DMI. And then remove DMI on/off switch at all (DMI will be always enabled). [1] http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation Strict DMI looks good. I didn't know it. Thats like white-listing methods. I will try it out and report. Thanks. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
2013/9/24 Paweł Wielgus : > One more side note, > if i understand it wright, > in my case (Edit input and execute methods) > wildcard mapping would be better from framework perspective > but it needs to be wriitten in xml configuration. > > Whereas DMI do not require me to write any xml, > but is not first class citizen in terms of framework. Yes, that's true. Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
One more side note, if i understand it wright, in my case (Edit input and execute methods) wildcard mapping would be better from framework perspective but it needs to be wriitten in xml configuration. Whereas DMI do not require me to write any xml, but is not first class citizen in terms of framework. Best greetings, Paweł Wielgus. 2013/9/24 Paweł Wielgus : > Hi Lukasz, > i see no problem for me in solution described by You. > Off course i'm no security expert here. > > Best greetings, > Paweł Wielgus. > > > 2013/9/23 Lukasz Lenart : >> 2013/9/23 Paweł Wielgus : >>> Hi all, >>> I'm using DMI to call "input" method extensively, >>> almost in every Edit*Action. >>> I call it with ParamsPrepareParams stack. >>> >>> I fully understand that allowing DMI is a security problem. >>> But maybe some kind of balance could be achevied. >>> White listing with annotations would not be bad for me >>> also maybe letting call only input (or similar) method by default >>> would not cause to much of a security problem? >>> >>> I'm not saying that i will drop S2 >>> if DMI will be disabled, >>> but sure it will make me rewrite all my edit actions. >> >> There is "strict dmi" [1] but I doubt that anybody is using it ;-) >> Anyway, doing some improvement in that area is better than removing >> DMI at all ;-) >> Maybe we should switch to strict dmi by default - e.g "execute, input, >> edit, submit, form" are the only allowed methods to be called via DMI. >> And then remove DMI on/off switch at all (DMI will be always enabled). >> >> [1] >> http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation >> >> >> Regards >> -- >> Łukasz >> + 48 606 323 122 http://www.lenart.org.pl/ >> >> - >> To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> For additional commands, e-mail: user-h...@struts.apache.org >> - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
Hi Lukasz, i see no problem for me in solution described by You. Off course i'm no security expert here. Best greetings, Paweł Wielgus. 2013/9/23 Lukasz Lenart : > 2013/9/23 Paweł Wielgus : >> Hi all, >> I'm using DMI to call "input" method extensively, >> almost in every Edit*Action. >> I call it with ParamsPrepareParams stack. >> >> I fully understand that allowing DMI is a security problem. >> But maybe some kind of balance could be achevied. >> White listing with annotations would not be bad for me >> also maybe letting call only input (or similar) method by default >> would not cause to much of a security problem? >> >> I'm not saying that i will drop S2 >> if DMI will be disabled, >> but sure it will make me rewrite all my edit actions. > > There is "strict dmi" [1] but I doubt that anybody is using it ;-) > Anyway, doing some improvement in that area is better than removing > DMI at all ;-) > Maybe we should switch to strict dmi by default - e.g "execute, input, > edit, submit, form" are the only allowed methods to be called via DMI. > And then remove DMI on/off switch at all (DMI will be always enabled). > > [1] > http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
2013/9/23 Volker Krebs : > Am 23.09.2013 11:05, schrieb Christoph Nenning: >>> >>> >>> Just a hint: DMI can be dangerous and we think about removing it. >>> >> That would force us to do heavy refactorings in all our applications. > > > Removing DMI completely would break a lot of applications. > How about white-listing methods ? > > At the moment we have a lot of trouble updating all our applications. > When DMI would be removed, we were forced to drop struts2 and re-implement. That's why I have posted my doubts - we consider so we need community's opinion Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
2013/9/23 Paweł Wielgus : > Hi all, > I'm using DMI to call "input" method extensively, > almost in every Edit*Action. > I call it with ParamsPrepareParams stack. > > I fully understand that allowing DMI is a security problem. > But maybe some kind of balance could be achevied. > White listing with annotations would not be bad for me > also maybe letting call only input (or similar) method by default > would not cause to much of a security problem? > > I'm not saying that i will drop S2 > if DMI will be disabled, > but sure it will make me rewrite all my edit actions. There is "strict dmi" [1] but I doubt that anybody is using it ;-) Anyway, doing some improvement in that area is better than removing DMI at all ;-) Maybe we should switch to strict dmi by default - e.g "execute, input, edit, submit, form" are the only allowed methods to be called via DMI. And then remove DMI on/off switch at all (DMI will be always enabled). [1] http://struts.apache.org/release/2.3.x/docs/action-configuration.html#ActionConfiguration-DynamicMethodInvocation Regards -- Łukasz + 48 606 323 122 http://www.lenart.org.pl/ - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [ANN] Struts 2.3.15.2 GA release available - security fix
Hi,
Yes, we know already :\ I'm working on a new solution, should be ready
next week.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/9/23 Emi Lu :
> Good morning,
>
> Upgraded from 2.3.15.1 to 15.2, but "s:submit" problem:
>
>
> (1) jsp:
> name= "loginForm"
>namespace= "/Login"
>action = "ProcessLoginAction"
>method = "post"
>theme="simple"
>>
>
>theme="simple"
> action="loginProcessLoginAction" /> --- never call
> loginProcessLoginAction
>
>
>
> (2) struts.xml
>
>
> main_menu
>
> /WEB-INF/pages/errorinfo/ajax_error_check.jsp
>
>
>
>
> (3) ProcessLoginAction.java
>public String login() throws Exception
>{
> try
> {
> ..
> }catch(Exception e)
> {
> log.error("login Error: " + e.getMessage());
> log.error(e);
> this.addActionError("login Error: " + e.getMessage());
> }
> return "success";
>}
>
>
> The problem is that "loginProcessLoginAction in jsp page" is never be
> called.
>
> Could you help?
> Thanks,
> Emi
>
>
>
> On 09/21/2013 12:06 PM, Lukasz Lenart wrote:
>>
>> The Apache Struts group is pleased to announce that Struts 2.3.15.2 is
>> available as a "General Availability" release.The GA designation is
>> our highest quality grade.
>>
>> Apache Struts 2 is an elegant, extensible framework for creating
>> enterprise-ready Java web applications. The framework is designed to
>> streamline the full development cycle, from building, to deploying, to
>> maintaining applications over time.
>>
>> This release includes important security fixes:
>> - S2-018 - Broken Access Control Vulnerability in Apache Struts2
>> - S2-019 - Dynamic Method Invocation disabled by default
>>
>> All developers are strongly advised to update existing Struts 2
>> applications to Struts 2.3.15.2
>>
>> Struts 2.3.15.2 is available in a full distribution, or as separate
>> library, source, example and documentation distributions, from the
>> releases page.
>> * http://struts.apache.org/download.cgi#struts23152
>>
>> The release is also available from the central Maven repository under
>> Group ID "org.apache.struts".
>>
>> The 2.3.x series of the Apache Struts framework has a minimum
>> requirement of the following specification versions:
>> * Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
>> * Java 2 Standard Platform Edition (J2SE) 5
>>
>> The release notes are available online at:
>> * http://struts.apache.org/release/2.3.x/docs/version-notes-23152.html
>>
>> Should any issues arise with your use of any version of the Struts
>> framework, please post your comments to the user list, and, if
>> appropriate, file a tracking ticket.appropriate, file a tracking
>> ticket:
>> * https://issues.apache.org/jira/browse/WW
>>
>>
>> - The Apache Struts group.
>>
>>
>> Regards
>>
>
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
Hi all, I'm using DMI to call "input" method extensively, almost in every Edit*Action. I call it with ParamsPrepareParams stack. I fully understand that allowing DMI is a security problem. But maybe some kind of balance could be achevied. White listing with annotations would not be bad for me also maybe letting call only input (or similar) method by default would not cause to much of a security problem? I'm not saying that i will drop S2 if DMI will be disabled, but sure it will make me rewrite all my edit actions. Best greetings, Paweł Wielgus. 2013/9/23 Volker Krebs : > Am 23.09.2013 11:05, schrieb Christoph Nenning: >>> >>> >>> Just a hint: DMI can be dangerous and we think about removing it. >>> >> That would force us to do heavy refactorings in all our applications. > > > Removing DMI completely would break a lot of applications. > How about white-listing methods ? > > At the moment we have a lot of trouble updating all our applications. > When DMI would be removed, we were forced to drop struts2 and re-implement. > > Greetings > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [ANN] Struts 2.3.15.2 GA release available - security fix
On 09/23/2013 10:38 AM, Volker Krebs wrote:
Am 23.09.2013 16:23, schrieb Emi Lu:
Good morning,
Upgraded from 2.3.15.1 to 15.2, but "s:submit" problem:
(1) jsp:
--- never call
loginProcessLoginAction
(2) struts.xml
main_menu
/WEB-INF/pages/errorinfo/ajax_error_check.jsp
(3) ProcessLoginAction.java
public String login() throws Exception
{
try
{
..
}catch(Exception e)
{
log.error("login Error: " + e.getMessage());
log.error(e);
this.addActionError("login Error: " + e.getMessage());
}
return "success";
}
The problem is that "loginProcessLoginAction in jsp page" is never be
called.
Could you help?
Thanks,
Emi
We have the same Problem.
This relates to http://struts.apache.org/release/2.3.x/docs/s2-018.html
But there it says
"Backward Compatibility
After upgrading to Struts >= 2.3.15.2, applications using the "action:"
should still work as expected."
I'm still trying to figure out what exactly the problem is.
I don't like this Security through obscurity approach.
The document does not say what 15.2 does not support related to
& in struts.xml.
What causing cannot do action anymore? How to fix it ?
Thanks a lot!
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: [ANN] Struts 2.3.15.2 GA release available - security fix
Am 23.09.2013 16:23, schrieb Emi Lu:
Good morning,
Upgraded from 2.3.15.1 to 15.2, but "s:submit" problem:
(1) jsp:
--- never call
loginProcessLoginAction
(2) struts.xml
main_menu
/WEB-INF/pages/errorinfo/ajax_error_check.jsp
(3) ProcessLoginAction.java
public String login() throws Exception
{
try
{
..
}catch(Exception e)
{
log.error("login Error: " + e.getMessage());
log.error(e);
this.addActionError("login Error: " + e.getMessage());
}
return "success";
}
The problem is that "loginProcessLoginAction in jsp page" is never be
called.
Could you help?
Thanks,
Emi
We have the same Problem.
This relates to http://struts.apache.org/release/2.3.x/docs/s2-018.html
But there it says
"Backward Compatibility
After upgrading to Struts >= 2.3.15.2, applications using the "action:"
should still work as expected."
I'm still trying to figure out what exactly the problem is.
I don't like this Security through obscurity approach.
Greetings
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: [ANN] Struts 2.3.15.2 GA release available - security fix
Good morning,
Upgraded from 2.3.15.1 to 15.2, but "s:submit" problem:
(1) jsp:
action="loginProcessLoginAction" /> --- never call
loginProcessLoginAction
(2) struts.xml
main_menu
/WEB-INF/pages/errorinfo/ajax_error_check.jsp
(3) ProcessLoginAction.java
public String login() throws Exception
{
try
{
..
}catch(Exception e)
{
log.error("login Error: " + e.getMessage());
log.error(e);
this.addActionError("login Error: " + e.getMessage());
}
return "success";
}
The problem is that "loginProcessLoginAction in jsp page" is never be
called.
Could you help?
Thanks,
Emi
On 09/21/2013 12:06 PM, Lukasz Lenart wrote:
The Apache Struts group is pleased to announce that Struts 2.3.15.2 is
available as a "General Availability" release.The GA designation is
our highest quality grade.
Apache Struts 2 is an elegant, extensible framework for creating
enterprise-ready Java web applications. The framework is designed to
streamline the full development cycle, from building, to deploying, to
maintaining applications over time.
This release includes important security fixes:
- S2-018 - Broken Access Control Vulnerability in Apache Struts2
- S2-019 - Dynamic Method Invocation disabled by default
All developers are strongly advised to update existing Struts 2
applications to Struts 2.3.15.2
Struts 2.3.15.2 is available in a full distribution, or as separate
library, source, example and documentation distributions, from the
releases page.
* http://struts.apache.org/download.cgi#struts23152
The release is also available from the central Maven repository under
Group ID "org.apache.struts".
The 2.3.x series of the Apache Struts framework has a minimum
requirement of the following specification versions:
* Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
* Java 2 Standard Platform Edition (J2SE) 5
The release notes are available online at:
* http://struts.apache.org/release/2.3.x/docs/version-notes-23152.html
Should any issues arise with your use of any version of the Struts
framework, please post your comments to the user list, and, if
appropriate, file a tracking ticket.appropriate, file a tracking
ticket:
* https://issues.apache.org/jira/browse/WW
- The Apache Struts group.
Regards
-
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
Am 23.09.2013 11:05, schrieb Christoph Nenning: Just a hint: DMI can be dangerous and we think about removing it. That would force us to do heavy refactorings in all our applications. Removing DMI completely would break a lot of applications. How about white-listing methods ? At the moment we have a lot of trouble updating all our applications. When DMI would be removed, we were forced to drop struts2 and re-implement. Greetings - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
> > Just a hint: DMI can be dangerous and we think about removing it. > That would force us to do heavy refactorings in all our applications. This Email was scanned by Sophos Anti Virus
Re: Url rewriting of .action to .jsp
Just a hint: DMI can be dangerous and we think about removing it. 2013/9/23 Christoph Nenning : > It seems a little late to join this discussion, but anyway here is what I > think. > > > Per default the framework shows validation errors for simple GET requests. > > The easiest way to work around that is to add "!input" to the url, like > this: > > login!input.action > > You can bookmark that and generate links to the page like that. > > > But I consider that rather ugly. > > > The solution proposed by Lukasz is to use 2 actions: one for GET requests > and another one for POST requests. I didn't think of that before. > > > > Here is what we usually do: > - action.execute() is used for displaying the page (GET requests) > - it returns INPUT (as it is the default for validation errors) > - the INPUT result is mapped to a tile > - enable DMI > - for POST requests the actions provide other methods like > login()/save()/create() > - those methods return a result name like "redisplay" which is mapped to a > actionRedirect result (redirect after POST) > - to invoke the other action methods we use parameter names prefixed with > "method:" > > That way we get nice URLs for GET requests and pages are shown without > validation errors per default. And we can handle the complete page in one > action class. > > > An issue that arises is to properly initialize actions. If validation > errors are present execute() is not invoked, so we use Prepareable to load > data we need to display (or init lists used for s and stuff like > that). But we have to take care that we don't override user input with DB > content in prepare(), so some initializtaion is done in prepare() and some > is done in execute(). > > To avoid that we use AJAX validation which makes actions much simpler. > > > > Regards, > Christoph > > > > >> >> "You cannot forward to actions" >> >> Thanks, that was the idea that was missing from my understanding. >> >> Got it working the way I wanted in a minute :) >> >> Many thanks - appreciated :) >> Serdyn du Toit >> >> >> >> On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart > wrote: >> >> > 2013/9/22 Serdyn du Toit : >> > > What I have now is as follows: >> > > extends="default"> >> > > >> > > >> > > /admin/login/login.jsp >> > > >> > > > > > class="com.d6.admin.login.AdminUserLoginAction"> >> > > name="input">/admin/login/login-form.htm >> > > > > name="success">/admin/dashboard/dashboard.htm >> > > >> > > >> > > >> > > The following part is just problematic - I'm struggling to find > these >> > > resources. My browser tells me "the requested resources is not >> > available", >> > > but when I hit the actions directly everything works 100% >> > >> > You cannot forward to actions - that what you do right now: > > name="input"> - changing extension to .htm doesn't change action >> > in a file. You can forward only to static resources (files), actions >> > are logical resources. >> > >> > Remove "struts.action.extension" - stick with default. >> > >> > Check out struts2-blank application and see how it is solved there - >> > example.xml, Login action class, Login.jsp and Login-validation.xml >> > >> > https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/ >> > >> > >> > Regards >> > -- >> > Łukasz >> > + 48 606 323 122 http://www.lenart.org.pl/ >> > >> > - >> > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org >> > For additional commands, e-mail: user-h...@struts.apache.org >> > >> > > > This Email was scanned by Sophos Anti Virus - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Url rewriting of .action to .jsp
It seems a little late to join this discussion, but anyway here is what I think. Per default the framework shows validation errors for simple GET requests. The easiest way to work around that is to add "!input" to the url, like this: login!input.action You can bookmark that and generate links to the page like that. But I consider that rather ugly. The solution proposed by Lukasz is to use 2 actions: one for GET requests and another one for POST requests. I didn't think of that before. Here is what we usually do: - action.execute() is used for displaying the page (GET requests) - it returns INPUT (as it is the default for validation errors) - the INPUT result is mapped to a tile - enable DMI - for POST requests the actions provide other methods like login()/save()/create() - those methods return a result name like "redisplay" which is mapped to a actionRedirect result (redirect after POST) - to invoke the other action methods we use parameter names prefixed with "method:" That way we get nice URLs for GET requests and pages are shown without validation errors per default. And we can handle the complete page in one action class. An issue that arises is to properly initialize actions. If validation errors are present execute() is not invoked, so we use Prepareable to load data we need to display (or init lists used for s and stuff like that). But we have to take care that we don't override user input with DB content in prepare(), so some initializtaion is done in prepare() and some is done in execute(). To avoid that we use AJAX validation which makes actions much simpler. Regards, Christoph > > "You cannot forward to actions" > > Thanks, that was the idea that was missing from my understanding. > > Got it working the way I wanted in a minute :) > > Many thanks - appreciated :) > Serdyn du Toit > > > > On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart wrote: > > > 2013/9/22 Serdyn du Toit : > > > What I have now is as follows: > > > > > > > > > > > > /admin/login/login.jsp > > > > > > > > class="com.d6.admin.login.AdminUserLoginAction"> > > > /admin/login/login-form.htm > > > > name="success">/admin/dashboard/dashboard.htm > > > > > > > > > > > > The following part is just problematic - I'm struggling to find these > > > resources. My browser tells me "the requested resources is not > > available", > > > but when I hit the actions directly everything works 100% > > > > You cannot forward to actions - that what you do right now: > name="input"> - changing extension to .htm doesn't change action > > in a file. You can forward only to static resources (files), actions > > are logical resources. > > > > Remove "struts.action.extension" - stick with default. > > > > Check out struts2-blank application and see how it is solved there - > > example.xml, Login action class, Login.jsp and Login-validation.xml > > > > https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/ > > > > > > Regards > > -- > > Łukasz > > + 48 606 323 122 http://www.lenart.org.pl/ > > > > - > > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > > For additional commands, e-mail: user-h...@struts.apache.org > > > > This Email was scanned by Sophos Anti Virus
Re: Url rewriting of .action to .jsp
"You cannot forward to actions" Thanks, that was the idea that was missing from my understanding. Got it working the way I wanted in a minute :) Many thanks - appreciated :) Serdyn du Toit On Mon, Sep 23, 2013 at 8:47 AM, Lukasz Lenart wrote: > 2013/9/22 Serdyn du Toit : > > What I have now is as follows: > > > > > > > > /admin/login/login.jsp > > > > > class="com.d6.admin.login.AdminUserLoginAction"> > > /admin/login/login-form.htm > > name="success">/admin/dashboard/dashboard.htm > > > > > > > > The following part is just problematic - I'm struggling to find these > > resources. My browser tells me "the requested resources is not > available", > > but when I hit the actions directly everything works 100% > > You cannot forward to actions - that what you do right now: name="input"> - changing extension to .htm doesn't change action > in a file. You can forward only to static resources (files), actions > are logical resources. > > Remove "struts.action.extension" - stick with default. > > Check out struts2-blank application and see how it is solved there - > example.xml, Login action class, Login.jsp and Login-validation.xml > > https://svn.apache.org/repos/asf/struts/struts2/trunk/apps/blank/ > > > Regards > -- > Łukasz > + 48 606 323 122 http://www.lenart.org.pl/ > > - > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > >
