You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ofbiz.apache.org by "Jacques Le Roux (JIRA)" <ji...@apache.org> on 2018/06/02 09:32:00 UTC

[jira] [Comment Edited] (OFBIZ-6766) Secure HTTP headers

    [ https://issues.apache.org/jira/browse/OFBIZ-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15058440#comment-15058440 ] 

Jacques Le Roux edited comment on OFBIZ-6766 at 6/2/18 9:31 AM:
----------------------------------------------------------------

I had a try at using HttpHeaderSecurityFilter and I must say I'm a bit dissapointed. Because like it's said at https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#web.xml you can't have both your own way and HttpHeaderSecurityFilter: <<HttpHeaderSecurityFilter can be used to add headers to responses to improve security. If clients access Tomcat directly, then you probably want to enable this filter and all the headers it sets unless your application is already setting them.>>.

Since, in RequestHandler class, I already covered all the points HttpHeaderSecurityFilter does (strict-transport-security, x-frame-options and x-content-type-options) there is not much interest in using it. It could even be counterproductive with duplicate or conflictings values. Moreover it does not handle X-XSS-Protection which is a breeze to set in RequestHandler. Finally doing so in RequestHandler has the advantage of not depending on Tomcat and cover not only OOTB web apps but any possible new ones.

I had also a go with CsrfPreventionFilter, same dissapointement. It's hard to set as explained at https://www.mail-archive.com/users@tomcat.apache.org/msg88601.html. I gave up at this stage, on other filters as well... That does not mean they should not be considered in a custom project...

Anyway all in all I prefer to handle security point by point rather than having a false sense of security relying on filters or what-not.


was (Author: jacques.le.roux):
I had a try at using HttpHeaderSecurityFilter and I must say I'm a bit dissapointed. Because like it's said at https://tomcat.apache.org/tomcat-7.0-doc/security-howto.html#web.xml you can't have both your own way and HttpHeaderSecurityFilter: <<HttpHeaderSecurityFilter can be used to add headers to responses to improve security. If clients access Tomcat directly, then you probably want to enable this filter and all the headers it sets unless your application is already setting them.>>.

Since, in RequestHandler class, I already covered all the points HttpHeaderSecurityFilter does (strict-transport-security, x-frame-options and x-content-type-options) there is not much interest in using it. It could even be counterproductive with duplicate or conflictings values. Moreover it does not handle X-XSS-Protection which is a breeze to set in RequestHandler. Finally doing so in RequestHandler has the advantage of not depending on Tomcat and cover not only OOTB web apps but any possible new ones.

I had also a go with RestCsrfPreventionFilter, same dissapointement. It's hard to set as explained at https://www.mail-archive.com/users@tomcat.apache.org/msg88601.html. I gave up at this stage, on other filters as well... That does not mean they should not be considered in a custom project...

Anyway all in all I prefer to handle security point by point rather than having a false sense of security relying on filters or what-not.

> Secure HTTP headers
> -------------------
>
>                 Key: OFBIZ-6766
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-6766
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: framework
>    Affects Versions: Trunk
>            Reporter: Jacques Le Roux
>            Assignee: Jacques Le Roux
>            Priority: Major
>             Fix For: 17.12.01
>
>         Attachments: OFBIZ-6766-UtilHttp.java.patch
>
>
> I have created a wiki page for this https://cwiki.apache.org/confluence/display/OFBIZ/How+to+Secure+HTTP+Headers



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)