I am currently not using any ajax stuff and i belive using JSON validation is
not the
solution I am looking for. Although I have no idea what it does i think it is
way too much for my little
and simple requirement and if is also not a good choice from design point of
view.
as i suggested and dave confirmed i will use an interceptor to escape the
parameters. but now i
have come to the following problem in my interceptor code:
public String intercept(ActionInvocation invocation) throws Exception {
Map<String,Object>
params = invocation.getInvocationContext().getParameters();
if (params.get("parameter_name") instanceof String){
//never entered???
String param_var= params.get("parameter_name");
//escape + write back ...
}
return invocation.invoke ();
}
It seems params.get("parameter_name") is returning an String [] instead of an
String. In my case it should return a String only.
As a workaround i could use:
HttpServletRequest request = (HttpServletRequest)
invocation.getInvocationContext ().get(HTTP_REQUEST);
String myParam = request.getParameter ("parameter_name");
but before I use this I would like to know why params.get("parameter_name") is
not returning a simple String?
Any idea?
Pars
________________________________
Von: Martin Gainty <[email protected]>
An: [email protected]
Gesendet: Montag, den 4. Oktober 2010, 23:27:55 Uhr
Betreff: RE: Best Practices for handling of XSS attacks
set struts.enableJSONValidation to true e.g.
-Dstruts.enableJSONValidation=true
OR configured as a parameter in web.xml\
<init-param>
<param-name>struts.enableJSONValidation</param-name>
<param-value>true</param-value>
</init-param>
to enable JSONValidationInterceptor assume struts<-default>.xml contains the
jsonValidation interceptor
<interceptors>
<interceptor name="jsonValidation"
class="org.apache.struts2.interceptor.validation.JSONValidationInterceptor" />
<!-- jsonValidation is configured in the jsonValidationWorkflowStack -->
<interceptor-stack name="jsonValidationWorkflowStack">
<interceptor-ref name="basicStack"/>
<interceptor-ref name="validation">
<param name="excludeMethods">input,back,cancel</param>
</interceptor-ref>
<interceptor-ref name="jsonValidation"/>
<interceptor-ref name="workflow"/>
</interceptor-stack>
<!-- the jsonValidationWorkflowStack should be defined as the
default-interceptor -->
<default-interceptor-ref name="jsonValidationWorkflowStack"/>
Viel Gluck,
martin
______________________________________________
Verzicht und Vertraulichkeitanmerkung
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung.
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung
fuer den Inhalt uebernehmen.
> Date: Mon, 4 Oct 2010 18:53:33 +0000
> From: [email protected]
> Subject: RE: Best Practices for handling of XSS attacks
> To: [email protected]
>
> yep, this is what i will do.
> Where in the defaultStack would you place such an interceptor from an
> architecual point of view?
>
> Pars
>
>
>
> ----- Ursprüngliche Mail ----
> Von: Dave Newton <[email protected]>
> An: Struts Users Mailing List <[email protected]>
> Gesendet: Montag, den 4. Oktober 2010, 19:59:14 Uhr
> Betreff: Re: Best Practices for handling of XSS attacks
>
> An interceptor is still a reasonable solution. But not having a form on each
> page doesn't really seem like a big deal--just escape any request
> parameters; no form, no parameters, no problem.
>
> Dave
>
> On Mon, Oct 4, 2010 at 11:55 AM, Pars Man <[email protected]> wrote:
>
> > I don't want to use HDIV because:
> > 1. i do not know muc about it (yet)
> > 2. seems to be "heavy weight" - I don't need all of its capabilities
> >
> > But I have the feeling you know more about HDIV. As far as I know HDIV also
> > changes urls, which I also don't want.
> > I just want to make my html forms secure against xss and nothing else. and
> > of
> > courese i fo not have a form on on every page...
> >
> > Pars
> >
> >
> >
> > ----- Ursprüngliche Mail ----
> > Von: Dave Newton <[email protected]>
> > An: Struts Users Mailing List <[email protected]>
> > Gesendet: Freitag, den 1. Oktober 2010, 14:46:03 Uhr
> > Betreff: Re: Best Practices for handling of XSS attacks
> >
> > An interceptor seems like a reasonable solution. Why don't you want to use
> > HDIV?
> >
> > Dave
> >
> > On Fri, Oct 1, 2010 at 3:15 AM, Pars Man <[email protected]> wrote:
> >
> > > Hi,
> > >
> > > I am currently checking the web to find something about how to handle XSS
> > > attacks in my Struts2 application.
> > > Unfortunately I just cannot find anything.
> > >
> > > I do not want to use HDIV (http://www.hdiv.org/) or the HDIV-Plugin
> > > (https://cwiki.apache.org/S2PLUGINS/home.html).
> > >
> > > What I thought of is an Interceptor that escapes the special characters
> > of
> > > all
> > > parameters that are sent, i.e. by using StringEscapeUtils which is
> > included
> > > in
> > > commons-lang.jar
> > > (see
> > http://www.mkyong.com/java/how-to-escape-special-characters-in-java/
> > > ).
> > >
> > > 1. How would you manage such a requirement?
> > > 2. What are the Best Practices?
> > > 3. Would you use an Interceptor and if yes how would it look like?
> > > 4. What options do I have?
> > > 5. What are the pros and cons?
> > >
> > > Thanks
> > >
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
