You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Tobias Soloschenko <to...@googlemail.com> on 2016/08/27 16:01:08 UTC

Security Check of Mozilla / Wicket implementation

Hi,

Mozilla just made a tool public which allows to scan websites for security risks. Maybe we can somehow add a default set of headers to the page rendering of Wicket / apply other security relevant implementations. Or we are able to make them at least optional:

https://observatory.mozilla.org

Example header:

https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection

What so you think about that idea?

kind regards

Tobias

Fwd: Re: Security Check of Mozilla / Wicket implementation

Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,

woops it is now A+ because of this in the web.xml:

     <!-- Force SSL for entire site -->
     <security-constraint>
         <web-resource-collection>
             <web-resource-name>Entire Application</web-resource-name>
             <url-pattern>/*</url-pattern>
         </web-resource-collection>
         <user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
         </user-data-constraint>
     </security-constraint>

kind regards

Tobias

-------- Weitergeleitete Nachricht --------
Betreff: 	Re: Security Check of Mozilla / Wicket implementation
Datum: 	Sun, 28 Aug 2016 15:52:32 +0200
Von: 	Tobias Soloschenko <to...@gmail.com>
An: 	dev@wicket.apache.org



Hi,

you are able to implement the security headers in a very easy way. See:

Mozilla tool to check web security: https://observatory.mozilla.org/

Demo wicket application (might be down or change after a while):
https://wicketsecurity-klopfdreh.rhcloud.com/

The test:
https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com

The implementation within your Wicket Application:

     @Override
     protected void init()
     {
         super.init();

         getRequestCycleListeners().add(new AbstractRequestCycleListener(){
             @Override
             public void onEndRequest(RequestCycle cycle)
             {
((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1;
mode=block");
((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security", "max-age=31536000;
includeSubDomains; preload");
((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options",
"nosniff");
((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options", "DENY");
((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
"default-src https:"); // Google "for Content-Security-Policy" to allow
more domains
             }
         });
     }

The result: >> A- << (because of redirection settings of tomcat - I was
not able to change them that fast)

To get A just enable a server redirect like mentioned here:

https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections

kind regards

Tobias

Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
> I think it would be a good idea to have something like this as an
> option in Wicket. Something to turn on with a one-liner for the
> application. There are a bunch of these headers that are useful, plus I
> recently came across this:
>
> https://dev.to/ben/the-targetblank-vulnerability-by-example
>
> Should we perhaps also add something that adds the rel="noopener"
> attribute to links with target="_blank"?
>
> I'm all for making these security things as easy as possible for the
> developer.
>
> Carl-Eric
>
> On Sat, 27 Aug 2016 18:08:36 +0200
> Martin Grigorov <mg...@apache.org> wrote:
>
>> Hi,
>>
>> We use Spring Security in all our applications.
>> It adds these response headers for free.
>>
>> Any other Servlet Filter could do the same but I don't mind adding
>> facilities in Wicket too.
>>
>> Btw one of the security experts from OWASP audited our applications
>> in the last few weeks. Although he've found few problems here and
>> there he said very nice words for Wicket!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
>> tobiassoloschenko@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> Mozilla just made a tool public which allows to scan websites for
>>> security risks. Maybe we can somehow add a default set of headers
>>> to the page rendering of Wicket / apply other security relevant
>>> implementations. Or we are able to make them at least optional:
>>>
>>> https://observatory.mozilla.org
>>>
>>> Example header:
>>>
>>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>>>
>>> What so you think about that idea?
>>>
>>> kind regards
>>>
>>> Tobias




Re: Security Check of Mozilla / Wicket implementation

Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,

good point! The settings I suggested were only a hint how to implement the security related topics of Mozillas Observatory into Wicket. The settings of course should be adjusted to the requirements of the web page. :-)

kind regards

Tobias

> Am 29.08.2016 um 08:41 schrieb Martin Spielmann <ma...@pingunaut.com>:
> 
> Hi,
> thanks a lot!
> Be careful with the "x-frame-options=deny". It will break ajax file uploads within your applications (which are implemented using an iframe). You could set it to "sameorigin" to make ajax file uploads work again, but I didn't have the chance to test if this changes the ranking in mozillas test.
> 
> Regards,
> Martin
> 
> Am 28. August 2016 23:57:30 MESZ, schrieb Carl-Eric Menzel <cm...@wicketbuch.de>:
>> Hi Tobias,
>> 
>> thanks for collecting the headers, that saves me the effort :-) I know
>> it's easy to write, I was just suggesting we add something like this to
>> Wicket itself. I'll see whether I can come up with something simple and
>> flexible enough.
>> 
>> One question: Why onEndRequest?
>> 
>> Carl-Eric
>> 
>> On Sun, 28 Aug 2016 15:52:32 +0200
>> Tobias Soloschenko <to...@googlemail.com> wrote:
>> 
>>> Hi,
>>> 
>>> you are able to implement the security headers in a very easy way.
>>> See:
>>> 
>>> Mozilla tool to check web security: https://observatory.mozilla.org/
>>> 
>>> Demo wicket application (might be down or change after a while): 
>>> https://wicketsecurity-klopfdreh.rhcloud.com/
>>> 
>>> The test:
>> https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com
>>> 
>>> The implementation within your Wicket Application:
>>> 
>>>     @Override
>>>     protected void init()
>>>     {
>>>         super.init();
>>> 
>>>         getRequestCycleListeners().add(new
>>> AbstractRequestCycleListener(){ @Override
>>>             public void onEndRequest(RequestCycle cycle)
>>>             {
>>> ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
>>> mode=block");
>> ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security",
>>> "max-age=31536000; includeSubDomains; preload");
>> ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
>>> "nosniff");
>>> ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options",
>>> "DENY");
>> ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
>>> "default-src https:"); // Google "for Content-Security-Policy" to
>>> allow more domains }
>>>         });
>>>     }
>>> 
>>> The result: >> A- << (because of redirection settings of tomcat - I
>>> was not able to change them that fast)
>>> 
>>> To get A just enable a server redirect like mentioned here:
>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections
>>> 
>>> kind regards
>>> 
>>> Tobias
>>> 
>>>> Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
>>>> I think it would be a good idea to have something like this as an
>>>> option in Wicket. Something to turn on with a one-liner for the
>>>> application. There are a bunch of these headers that are useful,
>>>> plus I recently came across this:
>>>> 
>>>> https://dev.to/ben/the-targetblank-vulnerability-by-example
>>>> 
>>>> Should we perhaps also add something that adds the rel="noopener"
>>>> attribute to links with target="_blank"?
>>>> 
>>>> I'm all for making these security things as easy as possible for
>> the
>>>> developer.
>>>> 
>>>> Carl-Eric
>>>> 
>>>> On Sat, 27 Aug 2016 18:08:36 +0200
>>>> Martin Grigorov <mg...@apache.org> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> We use Spring Security in all our applications.
>>>>> It adds these response headers for free.
>>>>> 
>>>>> Any other Servlet Filter could do the same but I don't mind adding
>>>>> facilities in Wicket too.
>>>>> 
>>>>> Btw one of the security experts from OWASP audited our
>> applications
>>>>> in the last few weeks. Although he've found few problems here and
>>>>> there he said very nice words for Wicket!
>>>>> 
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>> 
>>>>> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <  
>>>>> tobiassoloschenko@googlemail.com> wrote:  
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Mozilla just made a tool public which allows to scan websites for
>>>>>> security risks. Maybe we can somehow add a default set of headers
>>>>>> to the page rendering of Wicket / apply other security relevant
>>>>>> implementations. Or we are able to make them at least optional:
>>>>>> 
>>>>>> https://observatory.mozilla.org
>>>>>> 
>>>>>> Example header:
>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>>>>>> 
>>>>>> What so you think about that idea?
>>>>>> 
>>>>>> kind regards
>>>>>> 
>>>>>> Tobias  
> 
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Security Check of Mozilla / Wicket implementation

Posted by Martin Spielmann <ma...@pingunaut.com>.
Hi,
thanks a lot!
Be careful with the "x-frame-options=deny". It will break ajax file uploads within your applications (which are implemented using an iframe). You could set it to "sameorigin" to make ajax file uploads work again, but I didn't have the chance to test if this changes the ranking in mozillas test.

Regards,
Martin

Am 28. August 2016 23:57:30 MESZ, schrieb Carl-Eric Menzel <cm...@wicketbuch.de>:
>Hi Tobias,
>
>thanks for collecting the headers, that saves me the effort :-) I know
>it's easy to write, I was just suggesting we add something like this to
>Wicket itself. I'll see whether I can come up with something simple and
>flexible enough.
>
>One question: Why onEndRequest?
>
>Carl-Eric
>
>On Sun, 28 Aug 2016 15:52:32 +0200
>Tobias Soloschenko <to...@googlemail.com> wrote:
>
>> Hi,
>> 
>> you are able to implement the security headers in a very easy way.
>> See:
>> 
>> Mozilla tool to check web security: https://observatory.mozilla.org/
>> 
>> Demo wicket application (might be down or change after a while): 
>> https://wicketsecurity-klopfdreh.rhcloud.com/
>> 
>> The test: 
>>
>https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com
>> 
>> The implementation within your Wicket Application:
>> 
>>      @Override
>>      protected void init()
>>      {
>>          super.init();
>> 
>>          getRequestCycleListeners().add(new
>> AbstractRequestCycleListener(){ @Override
>>              public void onEndRequest(RequestCycle cycle)
>>              {
>> ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
>> mode=block");
>>
>((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security",
>> "max-age=31536000; includeSubDomains; preload");
>>
>((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
>> "nosniff");
>> ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options",
>> "DENY");
>>
>((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
>> "default-src https:"); // Google "for Content-Security-Policy" to
>> allow more domains }
>>          });
>>      }
>> 
>> The result: >> A- << (because of redirection settings of tomcat - I
>> was not able to change them that fast)
>> 
>> To get A just enable a server redirect like mentioned here:
>> 
>>
>https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections
>> 
>> kind regards
>> 
>> Tobias
>> 
>> Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
>> > I think it would be a good idea to have something like this as an
>> > option in Wicket. Something to turn on with a one-liner for the
>> > application. There are a bunch of these headers that are useful,
>> > plus I recently came across this:
>> >
>> > https://dev.to/ben/the-targetblank-vulnerability-by-example
>> >
>> > Should we perhaps also add something that adds the rel="noopener"
>> > attribute to links with target="_blank"?
>> >
>> > I'm all for making these security things as easy as possible for
>the
>> > developer.
>> >
>> > Carl-Eric
>> >
>> > On Sat, 27 Aug 2016 18:08:36 +0200
>> > Martin Grigorov <mg...@apache.org> wrote:
>> >  
>> >> Hi,
>> >>
>> >> We use Spring Security in all our applications.
>> >> It adds these response headers for free.
>> >>
>> >> Any other Servlet Filter could do the same but I don't mind adding
>> >> facilities in Wicket too.
>> >>
>> >> Btw one of the security experts from OWASP audited our
>applications
>> >> in the last few weeks. Although he've found few problems here and
>> >> there he said very nice words for Wicket!
>> >>
>> >> Martin Grigorov
>> >> Wicket Training and Consulting
>> >> https://twitter.com/mtgrigorov
>> >>
>> >> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <  
>> >> tobiassoloschenko@googlemail.com> wrote:  
>> >>  
>> >>> Hi,
>> >>>
>> >>> Mozilla just made a tool public which allows to scan websites for
>> >>> security risks. Maybe we can somehow add a default set of headers
>> >>> to the page rendering of Wicket / apply other security relevant
>> >>> implementations. Or we are able to make them at least optional:
>> >>>
>> >>> https://observatory.mozilla.org
>> >>>
>> >>> Example header:
>> >>>
>> >>>
>https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>> >>>
>> >>> What so you think about that idea?
>> >>>
>> >>> kind regards
>> >>>
>> >>> Tobias  
>> 

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Security Check of Mozilla / Wicket implementation

Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,

I just took one of the callbacks and thought that it is more save to add the headers at to the end of the request cycle. There is actually no concrete cause why onEndRequest.

kind regards

Tobias

> Am 28.08.2016 um 23:57 schrieb Carl-Eric Menzel <cm...@wicketbuch.de>:
> 
> Hi Tobias,
> 
> thanks for collecting the headers, that saves me the effort :-) I know
> it's easy to write, I was just suggesting we add something like this to
> Wicket itself. I'll see whether I can come up with something simple and
> flexible enough.
> 
> One question: Why onEndRequest?
> 
> Carl-Eric
> 
> On Sun, 28 Aug 2016 15:52:32 +0200
> Tobias Soloschenko <to...@googlemail.com> wrote:
> 
>> Hi,
>> 
>> you are able to implement the security headers in a very easy way.
>> See:
>> 
>> Mozilla tool to check web security: https://observatory.mozilla.org/
>> 
>> Demo wicket application (might be down or change after a while): 
>> https://wicketsecurity-klopfdreh.rhcloud.com/
>> 
>> The test: 
>> https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com
>> 
>> The implementation within your Wicket Application:
>> 
>>     @Override
>>     protected void init()
>>     {
>>         super.init();
>> 
>>         getRequestCycleListeners().add(new
>> AbstractRequestCycleListener(){ @Override
>>             public void onEndRequest(RequestCycle cycle)
>>             {
>> ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
>> mode=block");
>> ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security",
>> "max-age=31536000; includeSubDomains; preload");
>> ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
>> "nosniff");
>> ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options",
>> "DENY");
>> ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
>> "default-src https:"); // Google "for Content-Security-Policy" to
>> allow more domains }
>>         });
>>     }
>> 
>> The result: >> A- << (because of redirection settings of tomcat - I
>> was not able to change them that fast)
>> 
>> To get A just enable a server redirect like mentioned here:
>> 
>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections
>> 
>> kind regards
>> 
>> Tobias
>> 
>>> Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
>>> I think it would be a good idea to have something like this as an
>>> option in Wicket. Something to turn on with a one-liner for the
>>> application. There are a bunch of these headers that are useful,
>>> plus I recently came across this:
>>> 
>>> https://dev.to/ben/the-targetblank-vulnerability-by-example
>>> 
>>> Should we perhaps also add something that adds the rel="noopener"
>>> attribute to links with target="_blank"?
>>> 
>>> I'm all for making these security things as easy as possible for the
>>> developer.
>>> 
>>> Carl-Eric
>>> 
>>> On Sat, 27 Aug 2016 18:08:36 +0200
>>> Martin Grigorov <mg...@apache.org> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> We use Spring Security in all our applications.
>>>> It adds these response headers for free.
>>>> 
>>>> Any other Servlet Filter could do the same but I don't mind adding
>>>> facilities in Wicket too.
>>>> 
>>>> Btw one of the security experts from OWASP audited our applications
>>>> in the last few weeks. Although he've found few problems here and
>>>> there he said very nice words for Wicket!
>>>> 
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>> 
>>>> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <  
>>>> tobiassoloschenko@googlemail.com> wrote:  
>>>> 
>>>>> Hi,
>>>>> 
>>>>> Mozilla just made a tool public which allows to scan websites for
>>>>> security risks. Maybe we can somehow add a default set of headers
>>>>> to the page rendering of Wicket / apply other security relevant
>>>>> implementations. Or we are able to make them at least optional:
>>>>> 
>>>>> https://observatory.mozilla.org
>>>>> 
>>>>> Example header:
>>>>> 
>>>>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>>>>> 
>>>>> What so you think about that idea?
>>>>> 
>>>>> kind regards
>>>>> 
>>>>> Tobias  
> 

Re: Security Check of Mozilla / Wicket implementation

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
Hi Tobias,

thanks for collecting the headers, that saves me the effort :-) I know
it's easy to write, I was just suggesting we add something like this to
Wicket itself. I'll see whether I can come up with something simple and
flexible enough.

One question: Why onEndRequest?

Carl-Eric

On Sun, 28 Aug 2016 15:52:32 +0200
Tobias Soloschenko <to...@googlemail.com> wrote:

> Hi,
> 
> you are able to implement the security headers in a very easy way.
> See:
> 
> Mozilla tool to check web security: https://observatory.mozilla.org/
> 
> Demo wicket application (might be down or change after a while): 
> https://wicketsecurity-klopfdreh.rhcloud.com/
> 
> The test: 
> https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com
> 
> The implementation within your Wicket Application:
> 
>      @Override
>      protected void init()
>      {
>          super.init();
> 
>          getRequestCycleListeners().add(new
> AbstractRequestCycleListener(){ @Override
>              public void onEndRequest(RequestCycle cycle)
>              {
> ((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
> mode=block");
> ((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security",
> "max-age=31536000; includeSubDomains; preload");
> ((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
> "nosniff");
> ((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options",
> "DENY");
> ((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy",
> "default-src https:"); // Google "for Content-Security-Policy" to
> allow more domains }
>          });
>      }
> 
> The result: >> A- << (because of redirection settings of tomcat - I
> was not able to change them that fast)
> 
> To get A just enable a server redirect like mentioned here:
> 
> https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections
> 
> kind regards
> 
> Tobias
> 
> Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
> > I think it would be a good idea to have something like this as an
> > option in Wicket. Something to turn on with a one-liner for the
> > application. There are a bunch of these headers that are useful,
> > plus I recently came across this:
> >
> > https://dev.to/ben/the-targetblank-vulnerability-by-example
> >
> > Should we perhaps also add something that adds the rel="noopener"
> > attribute to links with target="_blank"?
> >
> > I'm all for making these security things as easy as possible for the
> > developer.
> >
> > Carl-Eric
> >
> > On Sat, 27 Aug 2016 18:08:36 +0200
> > Martin Grigorov <mg...@apache.org> wrote:
> >  
> >> Hi,
> >>
> >> We use Spring Security in all our applications.
> >> It adds these response headers for free.
> >>
> >> Any other Servlet Filter could do the same but I don't mind adding
> >> facilities in Wicket too.
> >>
> >> Btw one of the security experts from OWASP audited our applications
> >> in the last few weeks. Although he've found few problems here and
> >> there he said very nice words for Wicket!
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <  
> >> tobiassoloschenko@googlemail.com> wrote:  
> >>  
> >>> Hi,
> >>>
> >>> Mozilla just made a tool public which allows to scan websites for
> >>> security risks. Maybe we can somehow add a default set of headers
> >>> to the page rendering of Wicket / apply other security relevant
> >>> implementations. Or we are able to make them at least optional:
> >>>
> >>> https://observatory.mozilla.org
> >>>
> >>> Example header:
> >>>
> >>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
> >>>
> >>> What so you think about that idea?
> >>>
> >>> kind regards
> >>>
> >>> Tobias  
> 


Re: Security Check of Mozilla / Wicket implementation

Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,

you are able to implement the security headers in a very easy way. See:

Mozilla tool to check web security: https://observatory.mozilla.org/

Demo wicket application (might be down or change after a while): 
https://wicketsecurity-klopfdreh.rhcloud.com/

The test: 
https://observatory.mozilla.org/analyze.html?host=wicketsecurity-klopfdreh.rhcloud.com

The implementation within your Wicket Application:

     @Override
     protected void init()
     {
         super.init();

         getRequestCycleListeners().add(new AbstractRequestCycleListener(){
             @Override
             public void onEndRequest(RequestCycle cycle)
             {
((WebResponse)cycle.getResponse()).setHeader("X-XSS-Protection", "1; 
mode=block");
((WebResponse)cycle.getResponse()).setHeader("Strict-Transport-Security", "max-age=31536000; 
includeSubDomains; preload");
((WebResponse)cycle.getResponse()).setHeader("X-Content-Type-Options", 
"nosniff");
((WebResponse)cycle.getResponse()).setHeader("X-Frame-Options", "DENY");
((WebResponse)cycle.getResponse()).setHeader("Content-Security-Policy", 
"default-src https:"); // Google "for Content-Security-Policy" to allow 
more domains
             }
         });
     }

The result: >> A- << (because of redirection settings of tomcat - I was 
not able to change them that fast)

To get A just enable a server redirect like mentioned here:

https://wiki.mozilla.org/Security/Guidelines/Web_Security#HTTP_Redirections

kind regards

Tobias

Am 28.08.16 um 10:28 schrieb Carl-Eric Menzel:
> I think it would be a good idea to have something like this as an
> option in Wicket. Something to turn on with a one-liner for the
> application. There are a bunch of these headers that are useful, plus I
> recently came across this:
>
> https://dev.to/ben/the-targetblank-vulnerability-by-example
>
> Should we perhaps also add something that adds the rel="noopener"
> attribute to links with target="_blank"?
>
> I'm all for making these security things as easy as possible for the
> developer.
>
> Carl-Eric
>
> On Sat, 27 Aug 2016 18:08:36 +0200
> Martin Grigorov <mg...@apache.org> wrote:
>
>> Hi,
>>
>> We use Spring Security in all our applications.
>> It adds these response headers for free.
>>
>> Any other Servlet Filter could do the same but I don't mind adding
>> facilities in Wicket too.
>>
>> Btw one of the security experts from OWASP audited our applications
>> in the last few weeks. Although he've found few problems here and
>> there he said very nice words for Wicket!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
>> tobiassoloschenko@googlemail.com> wrote:
>>
>>> Hi,
>>>
>>> Mozilla just made a tool public which allows to scan websites for
>>> security risks. Maybe we can somehow add a default set of headers
>>> to the page rendering of Wicket / apply other security relevant
>>> implementations. Or we are able to make them at least optional:
>>>
>>> https://observatory.mozilla.org
>>>
>>> Example header:
>>>
>>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>>>
>>> What so you think about that idea?
>>>
>>> kind regards
>>>
>>> Tobias


Re: Security Check of Mozilla / Wicket implementation

Posted by Carl-Eric Menzel <cm...@wicketbuch.de>.
I think it would be a good idea to have something like this as an
option in Wicket. Something to turn on with a one-liner for the
application. There are a bunch of these headers that are useful, plus I
recently came across this:

https://dev.to/ben/the-targetblank-vulnerability-by-example

Should we perhaps also add something that adds the rel="noopener"
attribute to links with target="_blank"?

I'm all for making these security things as easy as possible for the
developer.

Carl-Eric

On Sat, 27 Aug 2016 18:08:36 +0200
Martin Grigorov <mg...@apache.org> wrote:

> Hi,
> 
> We use Spring Security in all our applications.
> It adds these response headers for free.
> 
> Any other Servlet Filter could do the same but I don't mind adding
> facilities in Wicket too.
> 
> Btw one of the security experts from OWASP audited our applications
> in the last few weeks. Although he've found few problems here and
> there he said very nice words for Wicket!
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
> tobiassoloschenko@googlemail.com> wrote:  
> 
> > Hi,
> >
> > Mozilla just made a tool public which allows to scan websites for
> > security risks. Maybe we can somehow add a default set of headers
> > to the page rendering of Wicket / apply other security relevant
> > implementations. Or we are able to make them at least optional:
> >
> > https://observatory.mozilla.org
> >
> > Example header:
> >
> > https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
> >
> > What so you think about that idea?
> >
> > kind regards
> >
> > Tobias  


Re: Security Check of Mozilla / Wicket implementation

Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Martin,

okay I am fine to let additional frameworks handle this facilities. Just wanted to mention it and ask for it here. :-)

Thanks for the fast response! 

kind regards

Tobias

> Am 27.08.2016 um 18:08 schrieb Martin Grigorov <mg...@apache.org>:
> 
> Hi,
> 
> We use Spring Security in all our applications.
> It adds these response headers for free.
> 
> Any other Servlet Filter could do the same but I don't mind adding
> facilities in Wicket too.
> 
> Btw one of the security experts from OWASP audited our applications in the
> last few weeks. Although he've found few problems here and there he said
> very nice words for Wicket!
> 
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
> 
> On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
> tobiassoloschenko@googlemail.com> wrote:
> 
>> Hi,
>> 
>> Mozilla just made a tool public which allows to scan websites for security
>> risks. Maybe we can somehow add a default set of headers to the page
>> rendering of Wicket / apply other security relevant implementations. Or we
>> are able to make them at least optional:
>> 
>> https://observatory.mozilla.org
>> 
>> Example header:
>> 
>> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>> 
>> What so you think about that idea?
>> 
>> kind regards
>> 
>> Tobias

Re: Security Check of Mozilla / Wicket implementation

Posted by Martin Grigorov <mg...@apache.org>.
Hi,

We use Spring Security in all our applications.
It adds these response headers for free.

Any other Servlet Filter could do the same but I don't mind adding
facilities in Wicket too.

Btw one of the security experts from OWASP audited our applications in the
last few weeks. Although he've found few problems here and there he said
very nice words for Wicket!

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Sat, Aug 27, 2016 at 6:01 PM, Tobias Soloschenko <
tobiassoloschenko@googlemail.com> wrote:

> Hi,
>
> Mozilla just made a tool public which allows to scan websites for security
> risks. Maybe we can somehow add a default set of headers to the page
> rendering of Wicket / apply other security relevant implementations. Or we
> are able to make them at least optional:
>
> https://observatory.mozilla.org
>
> Example header:
>
> https://wiki.mozilla.org/Security/Guidelines/Web_Security#X-XSS-Protection
>
> What so you think about that idea?
>
> kind regards
>
> Tobias