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 <[email protected]>: > > 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 <[email protected]> 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 <[email protected]> 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 < >>>> [email protected]> 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 >
