You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Lukasz Lenart <lu...@apache.org> on 2013/10/09 22:05:36 UTC
Security judges
Hi,
Another idea is to add some logic to handle security aspects of the
framework in one place - it would be some kind of stack of interfaces
which will try to cleanup incoming request.
For example:
- ActionNameJudge#accept() will handle if action name match expected
pattern, the same what is already defined with constant in
DefaultActionMapper
- ParameterNameJudge#accept() will handle if given parameter name is
acceptable - the same what ParametersInterceptor do right now
- etc
The idea is simple - have all the security related logic in one place
and to have it applied to the whole framework not to some parts, i.e.
someone will implement their own ActionMapper and won't escape/clear
action names as it is done in DefaultActionMapper, and so on.
These handlers will be configured in struts-default.xml and user can
re-define them, additional judges, etc.
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: Security judges
Posted by Paul Benedict <pb...@apache.org>.
Sounds like what Spring Security has:
http://docs.spring.io/spring-security/site/docs/2.0.x/apidocs/org/springframework/security/vote/AuthenticatedVoter.html
Each request goes through a list of voters.
Paul
On Thu, Oct 10, 2013 at 2:50 AM, Lukasz Lenart <lu...@apache.org>wrote:
> 2013/10/10 Steven Benitez <st...@gmail.com>:
> > Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm
> not
> > sure if it's best. What would the API look like?
>
> Not sure yet, something like this:
>
> public class SecurityGate {
>
> private List<SecurityGuard> guards;
>
> public void check(HttpServletRequest) {
> for(SecurityGuard guard : guards) {
> SecurityPass pass = guard.accept(HttpServletRequest);
> if (pass.notAccepted()) {
> throw new StrutsSecurityException(pass.getGuardMessage())
> }
> }
> }
>
> }
>
>
> 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
>
>
--
Cheers,
Paul
Re: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
As for now I will rollback my changes regarding this, maybe I will
come back to the idea in 2.3.17
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/10/18 Lukasz Lenart <lu...@apache.org>:
> 2013/10/17 Paul Benedict <pb...@apache.org>:
>> Throw an exception instead. If Struts has a default exception handler,
>> translate the exception into a 403; but the goal is to give the user a
>> chance to customize the response.
>
> That's the problem .... exceptions handling is provided by an
> interceptor, deep in execution chain and checking security at that
> level can be too late :\
>
> Right now I have added SecurityGate directly into Dispatcher and it
> will block the whole request if something suspicious will be
> discovered - and added two SecurityGuards, but they don't perform the
> real check now. They're there just to show the idea. Please review if
> it makes sense.
>
> https://issues.apache.org/jira/browse/WW-4227
>
>
> 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: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/17 Paul Benedict <pb...@apache.org>:
> Throw an exception instead. If Struts has a default exception handler,
> translate the exception into a 403; but the goal is to give the user a
> chance to customize the response.
That's the problem .... exceptions handling is provided by an
interceptor, deep in execution chain and checking security at that
level can be too late :\
Right now I have added SecurityGate directly into Dispatcher and it
will block the whole request if something suspicious will be
discovered - and added two SecurityGuards, but they don't perform the
real check now. They're there just to show the idea. Please review if
it makes sense.
https://issues.apache.org/jira/browse/WW-4227
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: Security judges
Posted by Paul Benedict <pb...@apache.org>.
Throw an exception instead. If Struts has a default exception handler,
translate the exception into a 403; but the goal is to give the user a
chance to customize the response.
On Thu, Oct 17, 2013 at 6:46 AM, Lukasz Lenart <lu...@apache.org>wrote:
> 2013/10/10 Lukasz Lenart <lu...@apache.org>:
> > 2013/10/10 Steven Benitez <st...@gmail.com>:
> >> Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm
> not
> >> sure if it's best. What would the API look like?
> >
> > Not sure yet, something like this:
> >
> > public class SecurityGate {
> >
> > private List<SecurityGuard> guards;
> >
> > public void check(HttpServletRequest) {
> > for(SecurityGuard guard : guards) {
> > SecurityPass pass = guard.accept(HttpServletRequest);
> > if (pass.notAccepted()) {
> > throw new StrutsSecurityException(pass.getGuardMessage())
> > }
> > }
> > }
> >
> > }
>
> Right now I'm planning just to throw an exception and call
> sendError(HttpServletResponse.SC_BAD_REQUEST, e.getMessage()), WDYT?
>
>
> 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
>
>
--
Cheers,
Paul
Re: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/10 Lukasz Lenart <lu...@apache.org>:
> 2013/10/10 Steven Benitez <st...@gmail.com>:
>> Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
>> sure if it's best. What would the API look like?
>
> Not sure yet, something like this:
>
> public class SecurityGate {
>
> private List<SecurityGuard> guards;
>
> public void check(HttpServletRequest) {
> for(SecurityGuard guard : guards) {
> SecurityPass pass = guard.accept(HttpServletRequest);
> if (pass.notAccepted()) {
> throw new StrutsSecurityException(pass.getGuardMessage())
> }
> }
> }
>
> }
Right now I'm planning just to throw an exception and call
sendError(HttpServletResponse.SC_BAD_REQUEST, e.getMessage()), WDYT?
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: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/10 Steven Benitez <st...@gmail.com>:
> Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
> sure if it's best. What would the API look like?
Not sure yet, something like this:
public class SecurityGate {
private List<SecurityGuard> guards;
public void check(HttpServletRequest) {
for(SecurityGuard guard : guards) {
SecurityPass pass = guard.accept(HttpServletRequest);
if (pass.notAccepted()) {
throw new StrutsSecurityException(pass.getGuardMessage())
}
}
}
}
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: Security judges
Posted by Steven Benitez <st...@gmail.com>.
Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
sure if it's best. What would the API look like?
On Thursday, October 10, 2013, Lukasz Lenart wrote:
> 2013/10/10 Lukasz Lenart <lukaszlenart@apache.org <javascript:;>>:
> > 2013/10/10 Paul Benedict <pbenedict@apache.org <javascript:;>>:
> >> I like the idea except the Judge name. I think Authenticator is fine.
> >
> > Hm... basically what the interfaces do is to judge if e.g. action name
> > is proper, parameter name matches given pattern, etc. It's some kind
> > of authentication of request but rather in validation terms (I don't
> > want to have another set of validators ;-)) Also users can have false
> > fillings that Struts provides some built-in authentication mechanism
> > (search phrase: struts authentication can point them to that logic).
> >
> > That's why SecurityJudge :-)
>
> Or SecurityGuard :-)
>
>
> Regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@struts.apache.org <javascript:;>
>
>
Re: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/10 Lukasz Lenart <lu...@apache.org>:
> 2013/10/10 Paul Benedict <pb...@apache.org>:
>> I like the idea except the Judge name. I think Authenticator is fine.
>
> Hm... basically what the interfaces do is to judge if e.g. action name
> is proper, parameter name matches given pattern, etc. It's some kind
> of authentication of request but rather in validation terms (I don't
> want to have another set of validators ;-)) Also users can have false
> fillings that Struts provides some built-in authentication mechanism
> (search phrase: struts authentication can point them to that logic).
>
> That's why SecurityJudge :-)
Or SecurityGuard :-)
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: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/10 Paul Benedict <pb...@apache.org>:
> I like the idea except the Judge name. I think Authenticator is fine.
Hm... basically what the interfaces do is to judge if e.g. action name
is proper, parameter name matches given pattern, etc. It's some kind
of authentication of request but rather in validation terms (I don't
want to have another set of validators ;-)) Also users can have false
fillings that Struts provides some built-in authentication mechanism
(search phrase: struts authentication can point them to that logic).
That's why SecurityJudge :-)
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: Security judges
Posted by Paul Benedict <pb...@apache.org>.
I like the idea except the Judge name. I think Authenticator is fine.
On Wed, Oct 9, 2013 at 3:21 PM, Steven Benitez <st...@gmail.com>wrote:
> Can you clarify how this would affect custom action mappers?
>
>
> On Wed, Oct 9, 2013 at 4:05 PM, Lukasz Lenart <lukaszlenart@apache.org
> >wrote:
>
> > Hi,
> >
> > Another idea is to add some logic to handle security aspects of the
> > framework in one place - it would be some kind of stack of interfaces
> > which will try to cleanup incoming request.
> >
> > For example:
> >
> > - ActionNameJudge#accept() will handle if action name match expected
> > pattern, the same what is already defined with constant in
> > DefaultActionMapper
> > - ParameterNameJudge#accept() will handle if given parameter name is
> > acceptable - the same what ParametersInterceptor do right now
> > - etc
> >
> > The idea is simple - have all the security related logic in one place
> > and to have it applied to the whole framework not to some parts, i.e.
> > someone will implement their own ActionMapper and won't escape/clear
> > action names as it is done in DefaultActionMapper, and so on.
> >
> > These handlers will be configured in struts-default.xml and user can
> > re-define them, additional judges, etc.
> >
> >
> > 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
> >
> >
>
--
Cheers,
Paul
Re: Security judges
Posted by Lukasz Lenart <lu...@apache.org>.
2013/10/9 Steven Benitez <st...@gmail.com>:
> Can you clarify how this would affect custom action mappers?
The whole stack will be executed before action mappers, I think in
prepare operations. Thus still needs some clarification, but I want to
make a security guard of the framework :-)
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: Security judges
Posted by Steven Benitez <st...@gmail.com>.
Can you clarify how this would affect custom action mappers?
On Wed, Oct 9, 2013 at 4:05 PM, Lukasz Lenart <lu...@apache.org>wrote:
> Hi,
>
> Another idea is to add some logic to handle security aspects of the
> framework in one place - it would be some kind of stack of interfaces
> which will try to cleanup incoming request.
>
> For example:
>
> - ActionNameJudge#accept() will handle if action name match expected
> pattern, the same what is already defined with constant in
> DefaultActionMapper
> - ParameterNameJudge#accept() will handle if given parameter name is
> acceptable - the same what ParametersInterceptor do right now
> - etc
>
> The idea is simple - have all the security related logic in one place
> and to have it applied to the whole framework not to some parts, i.e.
> someone will implement their own ActionMapper and won't escape/clear
> action names as it is done in DefaultActionMapper, and so on.
>
> These handlers will be configured in struts-default.xml and user can
> re-define them, additional judges, etc.
>
>
> 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
>
>