ParametersInterceptor: Can we inject a filter?

[Christian Stone <xt...@stonescape.net>]

I have been updating my distributions, but still see many attempts to compromise my installation through parameter submission like this:

ERROR

com.opensymphony.xwork2.interceptor.ParametersInterceptor

Developer Notification (set struts.devMode to false to disable this message):
Unexpected Exception caught setting 'redirect:${#res=#context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),#res.setCharacterEncoding("UTF-8"),#req=#context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),#res.getWriter().print("dir:"),#res.getWriter().println(#req.getSession().getServletContext().getRealPath("/")),#res.getWriter().flush(),#res.getWriter().close()}' on 'class java.lang.String: 100

I have an IP based blacklist and expiry for people who attempt invalid mail submissions (injecting mail commands in subjects programatically, etc.) It works really well to blacklist IPs temporarily. I would like to do the same with these kind of submissions. If someone attempts to inject commands in parameters, I would like to be able to intercept that and ban them.

I know I can insert an interceptor before ParametersInterceptor is called. I would rather be able to catch when a parameter is not there or banned, or the length is inappropriate and have a chance to respond. It would also cut down the number of interceptors and improve response time. I would also like to not need a custom ParametersInterceptor, as it can be problematic to update with new Struts releases.

Can anyone help me with a new perspective or solution to this problem? Is anyone interested in a solution if I code a handler for bad requests, and insert code into ParametersInterceptor to allow the handler to process the bad response. My thought is that it would take the package, action, parameter, value, and the parameters map as values.

Thanks for you thoughts!

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

Re: ParametersInterceptor: Can we inject a filter?

[Lukasz Lenart <lu...@apache.org>]

2015-04-29 18:03 GMT+02:00 Christian Stone <xt...@stonescape.net>:
> I have been updating my distributions, but still see many attempts to compromise my installation through parameter submission like this:
>
> ERROR
>
> com.opensymphony.xwork2.interceptor.ParametersInterceptor
>
> Developer Notification (set struts.devMode to false to disable this message):
> Unexpected Exception caught setting 'redirect:${#res=#context.get('com.opensymphony.xwork2.dispatcher.HttpServletResponse'),#res.setCharacterEncoding("UTF-8"),#req=#context.get('com.opensymphony.xwork2.dispatcher.HttpServletRequest'),#res.getWriter().print("dir:"),#res.getWriter().println(#req.getSession().getServletContext().getRealPath("/")),#res.getWriter().flush(),#res.getWriter().close()}' on 'class java.lang.String: 100
>
> I have an IP based blacklist and expiry for people who attempt invalid mail submissions (injecting mail commands in subjects programatically, etc.) It works really well to blacklist IPs temporarily. I would like to do the same with these kind of submissions. If someone attempts to inject commands in parameters, I would like to be able to intercept that and ban them.
>
> I know I can insert an interceptor before ParametersInterceptor is called. I would rather be able to catch when a parameter is not there or banned, or the length is inappropriate and have a chance to respond. It would also cut down the number of interceptors and improve response time. I would also like to not need a custom ParametersInterceptor, as it can be problematic to update with new Struts releases.
>
> Can anyone help me with a new perspective or solution to this problem? Is anyone interested in a solution if I code a handler for bad requests, and insert code into ParametersInterceptor to allow the handler to process the bad response. My thought is that it would take the package, action, parameter, value, and the parameters map as values.

Contributions based on real user's experience are always welcome :)
Right now I don't see an easy fix to your problem, request flow cannot
be intercepted because of wrong paramter's value, but I think it's
doable :)


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