date:20160828

Re: Security Check of Mozilla / Wicket implementation

2016-08-28 Thread Tobias Soloschenko

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 :
> 
> 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  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  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 <  
 tobiassolosche...@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

2016-08-28 Thread Carl-Eric Menzel

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  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  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 <  
> >> tobiassolosche...@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  
>

Fwd: Re: Security Check of Mozilla / Wicket implementation

2016-08-28 Thread Tobias Soloschenko


Hi,

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




Entire Application
/*


CONFIDENTIAL



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 
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  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 <
tobiassolosche...@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

2016-08-28 Thread Tobias Soloschenko


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  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 <
tobiassolosche...@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: Fragment's markup identifier change proposals for Wicket 8

2016-08-28 Thread Pedro Santos

Oh, good point. Indeed my first idea is pretty much not possible [1].

I meant the snippet with concrete subclasses only to illustrate the idea
since fragments can be created even without a Fragment subclass. My point
here is that even the Fragment being a concrete class, it still is an
abstract Wicket markup container. A concrete Wicket markup container has an
associated markup. When we associate the a markup to a Fragment, we are
creating a concrete Wicket type, and this type needs a name. Therefore the
importance I see in to keeping the "type" word in the identifier attribute.

Regarding the attribute namespace, I'm +1 to default it to Wicket's
namespece (like the "key" attribute in wicket:message tag usually defaults)
rather than to explicitly write the namespace. e.g.:

Given the .java
...
add(new Fragment("myId", "MyFragment", this);
...

I would prefer the following usage in the .xhtml
...

...
rather than
...

...

1 - https://www.w3.org/TR/REC-xml/#id

Pedro Santos

On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov 
wrote:

> Hi Pedro,
>
> In both examples you make the assumption that there is a concrete class
> extending from Fragment.
> As with many other cases in Wicket it is quite common to use anonymous
> inner class: return new Fragment(...) {}
> In this case the name/id would be something like "MyContainer$1" which is
> not so nice and more importantly it is not stable! It will change as soon
> as another anonymous inner class is added before the Fragment.
>
> My personal preference would be:  wicket:name="myCustomFragmentName">
>
> The problem that I see with  is that 'id' has a
> special meaning in XML - it has to be unique in the document.
> Most of the time s are defined as top-level elements in
> MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
> something like:
>
> 
>
>
>   
> 
>   
>
>
>   
> .
>   
> 
>
>
> In this case any XML validation tool will complain that there are two
> elements with the same id. The IDE as well.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, Aug 28, 2016 at 7:28 AM, Pedro Santos  wrote:
>
> > Hi devs,
> >
> > the "wicket:id" tag attribute is commonly used to identify Component's
> > instances and its markup, and IMO it should be reserved to this end for
> > clarity.
> >
> > While fragment's markup is identified by the "associatedMarkupId"
> attribute
> > inside the Fragment class, its associated markup is identified by the tag
> > attribute "wicket:id" in the "wicket:fragment" tag. This new case of an
> > associated markup being identified for a type rather than an instance
> would
> > benefit from a new identifier name. Therefore some proposals.
> >
> > 1 - Without changing the Fragment class, a natural tag attribute
> identifier
> > would "wicket:markup-id", matching the class attribute name. Since the
> > identifier is already inside a markup, even more natural would be:
> > "wicket:id" (yeah, I know). Given that we are already inside a tag in
> > Wicket's namespace, a simpler identifier would be: "id".
> >
> > So instead of the current fragment definition:
> >
> > class MyFragment extends Fragment {
> > ...
> > super(id, "myFragmentMarkupId", markupContainer);
> > ...
> > }
> > 
> >
> > We would have:
> >
> > 
> >
> > 2 - To change Fragment's "associatedMarkupId" attribute to "typeName".
> Even
> > if the user chooses to not specialize the Fragment class by creating a
> > subclass of it, conceptually he is still specializing the markup
> container
> > when associating a markup to it. Following the same
> logic,"wicket:fragment"
> > tag's identifier attribute would be: "type-name". So we would have:
> >
> > class MyFragment extends Fragment {
> > ...
> > super(id, MyFragment.class.getSimpleName(), markupContainer);
> > ...
> > }
> > 
> >
> > What are your thought?
> >
> > Cheers
> >
> > Pedro Santos
> >
>

Re: Security Check of Mozilla / Wicket implementation

2016-08-28 Thread 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  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 <
> tobiassolosche...@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: Fragment's markup identifier change proposals for Wicket 8

2016-08-28 Thread Martin Grigorov

Hi Pedro,

In both examples you make the assumption that there is a concrete class
extending from Fragment.
As with many other cases in Wicket it is quite common to use anonymous
inner class: return new Fragment(...) {}
In this case the name/id would be something like "MyContainer$1" which is
not so nice and more importantly it is not stable! It will change as soon
as another anonymous inner class is added before the Fragment.

My personal preference would be: 

The problem that I see with  is that 'id' has a
special meaning in XML - it has to be unique in the document.
Most of the time s are defined as top-level elements in
MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
something like:

.

In this case any XML validation tool will complain that there are two
elements with the same id. The IDE as well.

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

On Sun, Aug 28, 2016 at 7:28 AM, Pedro Santos  wrote:

> Hi devs,
>
> the "wicket:id" tag attribute is commonly used to identify Component's
> instances and its markup, and IMO it should be reserved to this end for
> clarity.
>
> While fragment's markup is identified by the "associatedMarkupId" attribute
> inside the Fragment class, its associated markup is identified by the tag
> attribute "wicket:id" in the "wicket:fragment" tag. This new case of an
> associated markup being identified for a type rather than an instance would
> benefit from a new identifier name. Therefore some proposals.
>
> 1 - Without changing the Fragment class, a natural tag attribute identifier
> would "wicket:markup-id", matching the class attribute name. Since the
> identifier is already inside a markup, even more natural would be:
> "wicket:id" (yeah, I know). Given that we are already inside a tag in
> Wicket's namespace, a simpler identifier would be: "id".
>
> So instead of the current fragment definition:
>
> class MyFragment extends Fragment {
> ...
> super(id, "myFragmentMarkupId", markupContainer);
> ...
> }
> 
>
> We would have:
>
> 
>
> 2 - To change Fragment's "associatedMarkupId" attribute to "typeName". Even
> if the user chooses to not specialize the Fragment class by creating a
> subclass of it, conceptually he is still specializing the markup container
> when associating a markup to it. Following the same logic,"wicket:fragment"
> tag's identifier attribute would be: "type-name". So we would have:
>
> class MyFragment extends Fragment {
> ...
> super(id, MyFragment.class.getSimpleName(), markupContainer);
> ...
> }
> 
>
> What are your thought?
>
> Cheers
>
> Pedro Santos
>

Re: Security Check of Mozilla / Wicket implementation

Re: Security Check of Mozilla / Wicket implementation

Fwd: Re: Security Check of Mozilla / Wicket implementation

Re: Security Check of Mozilla / Wicket implementation

Re: Fragment's markup identifier change proposals for Wicket 8

Re: Security Check of Mozilla / Wicket implementation

Re: Fragment's markup identifier change proposals for Wicket 8

7 matches

Site Navigation

Mail list logo

Footer information