Thank you very much to all of you for taking the time answer my
questions, i have a clearer view of my situation now,
Eric: I believe i understand your point , it's best for security
related stuff to be taylored for each individual project needs,
there's no way to be 100% sure of one's invulnerability, and in any case
it's better to check vulnerability issues from time to time and see
what can one do about it. There's no holy grail for that, nor any
magical solution, i'm aware of that.
One should make the best adn try to protect the system, and learn for
past experiences (past attacks).
Thanks a lot for sharing what would be a good strategy to deal with this
kind of stuff.
Lukasz: As i told to Eric i think we're gonna implement some additional
security checking mechanism, maybe a last Interceptor in the stack,
we'll see.
"for question 2)Prepare interceptor: So there's no way of remove the
"prepare" prefix? Maybe other implementation of that Interceptor?
It is, it depends on your needs, you can change default stack
configuration - read about stacks in Struts. (...)"
About PrepareInterceptor: i have the very same stack we've been using
for some years now, it has always been working ok with this order, we're
using the
paramsPrepareParamsStack , it's defined as follows:
<interceptor-stack name="paramsPrepareParamsStack">
<interceptor-ref name="exception"/>
<interceptor-ref name="alias"/>
<interceptor-ref name="i18n"/>
<interceptor-ref name="checkbox"/>
<interceptor-ref name="multiselect"/>
<interceptor-ref name="params">
<param
name="excludeParams">^dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,^parameters\..*,^action:.*,^method:.*</param>
</interceptor-ref>
<interceptor-ref name="servletConfig"/>
<interceptor-ref name="prepare"/>
<interceptor-ref name="chain"/>
<interceptor-ref name="modelDriven"/>
<interceptor-ref name="fileUpload"/>
<interceptor-ref name="staticParams"/>
<interceptor-ref name="actionMappingParams"/>
<interceptor-ref name="params">
<param
name="excludeParams">^dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,^parameters\..*,^action:.*,^method:.*</param>
</interceptor-ref>
<interceptor-ref name="conversionError"/>
<interceptor-ref name="validation">
<param
name="excludeMethods">input,back,cancel,browse</param>
</interceptor-ref>
<interceptor-ref name="workflow">
<param
name="excludeMethods">input,back,cancel,browse</param>
</interceptor-ref>
</interceptor-stack>
"(...)And when do you see that
the prepareXXX method is called? In logs? In debug mode? Why do think
it is a problem?"
I'm debugging
com.opensymphony.xwork2.interceptor.PrefixMethodInvocationUtil.java
in the method public static void invokePrefixMethod(ActionInvocation
actionInvocation, String[] prefixes) throws InvocationTargetException,
IllegalAccessException {
Method method = getPrefixedMethod(prefixes, methodName, action);
< wich in turn calls >
public static Method getPrefixedMethod(String[] prefixes,
String methodName, Object action) {
< here's where the methodName is prefixed >
String prefixedMethodName = prefixe + capitalizedMethodName;
It's not a problem per se but up to the latest version of the framework
i've been using , struts 2.1.8 , that wasn't happening, no appending at all,
if a specified <s:submit action="Action_method" > the method invocated
would have been "method()" and not "prepareMethod()" or "doPrepareMethod()"
like it's happening now. Basically i would have to rewrite the whole
application again regarding method names, i'd like to avoid that if
possible.
Maybe there's some congi tweaking to do with that issue.
Well, that's all for now, if i can get rid of this
prepare-prefix-appending-issue then i can research and tune up the
project so we can gain some extra security
while still using the action.prefix approach getting to some sort of
compromise between security and keeping the legacy stuff with not so
many changes.
Again, i want to thanks all the comunity for all their great responses,
attention and help, very appreciated,
Greetings to you all!!
Cheerz!!
El 30/01/2014 9:30, Lukasz Lenart escribió:
2014-01-30 Fabian Richter <frich...@mtg.de>:
Am 30.01.2014 06:57, schrieb Lukasz Lenart:
Do not depend only on container authentication mechanism.
So you would discourage the use of like Spring Security as a sole
authentication mechanism? Why?
You missed out the context - action: prefix vulnerability
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
