By curiosity I ran the "OWASP Zed Attack Proxy Project"
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project against
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
Good news, after 3 hours I found only limited warnings and I think we can
mostly neglect them, they are
Medium level:
Session ID in URL rewrite
http://demo-trunk-ofbiz.apache.org/catalog/control/main;jsessionid=D17A72BB22C495D1FCAAE011B3850D84.jvm1
URL rewrite is used to track user session ID. The session ID may be disclosed in referer header. Besides, the session ID can be stored in browser
history or server logs.
Since we want this, I see no reason to change it. Custom projects might
consider other solutions
Low level:
Cookie set without HttpOnly flag
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
Set-Cookie: OFBiz.Visitor=10013; Expires=Fri, 15-Jan-2016 07:04:07 GMT;
Path=/
Set-Cookie: catalog.autoUserLoginId=admin; Domain=""; Expires=Fri,
15-Jan-2016 07:04:07 GMT; Path=/
A cookie has been set without the HttpOnly flag, which means that the cookie can be accessed by JavaScript. If a malicious script can be run on
this page then the cookie will be accessible and can be transmitted to another site. If this is a session cookie then session hijacking may be possible.
We should consider this warning (see www.owasp.org/index.php/HttpOnly)
Note that Set-Cookie: JSESSIONID=5A4CB8126DD1ABAF9D712A2212271E31.jvm1;
Path=/catalog/; HttpOnly is ok
Cross-domain JavaScript source file inclusion
http://demo-trunk-ofbiz.apache.org/ebay/control/main?externalLoginKey=EL251768460309
http://demo-trunk.ofbiz.apache.org/images/jquery/jquery-1.11.0.min.js
Ensure JavaScript source files are loaded from only trusted sources, and
the sources can't be controlled by end users of the application
We want this and alike so no worries
Password Autocomplete in browser
http://demo-trunk-ofbiz.apache.org/projectmgr/control/taskView?id=9100&workEffortId=9100
<input type="password" name="PASSWORD" value="" size="20"/>
AUTOCOMPLETE attribute is not disabled in HTML FORM/INPUT element
containing password type input. Passwords may be stored in browsers and
retrieved.
I personnaly prefer to have this OOTB. Custom projects might not
Referer expose session ID
http://demo-trunk-ofbiz.apache.org/catalog/control/main;jsessionid=D17A72BB22C495D1FCAAE011B3850D84.jvm1
www.apache.org
Hyperlink to other host name is found. As session ID URL rewrite is used,
it may be disclosed in referer header to external host.
This is a risk if the session ID is sensitive and the hyperlink refer to an external host. For secure content, put session ID in secured session
cookie.
Not a worry here.
Web Browser XSS Protection Not Enabled
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
Web Browser XSS Protection is not enabled, or is disabled by the
configuration of the 'X-XSS-Protection' HTTP response header on the web server
The X-XSS-Protection HTTP response header allows the web server to enable or disable the web browser's XSS protection mechanism. The following
values would attempt to enable it:
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=http://www.example.com/xss
The following values would disable it:
X-XSS-Protection: 0
The X-XSS-Protection HTTP response header is currently supported on
Internet Explorer, Chrome and Safari (WebKit).
Note that this alert is only raised if the response body could potentially contain an XSS payload (with a text-based content type, with a
non-zero length).
We could consider this warning even if at the moment we have nothing to fear. Solution: Ensure that the web browser's XSS filter is enabled, by
setting the X-XSS-Protection HTTP response header to '1'.
X-Content-Type-Options header missing
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
The Anti-MIME-Sniffing header X-Content-Type-Options was not set to 'nosniff'. This allows older versions of Internet Explorer and Chrome to
perform MIME-sniffing on the response body, potentially causing the response body to be interpreted and displayed as a content type other than the
declared content type. Current (early 2014) and legacy versions of Firefox will use the declared content type (if one is set), rather than performing
MIME-sniffing.
Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for
all web pages.
We can neglect this warning, with new browsers policies, people should now have
not automatic updates
X-Frame-Options header not set
http://demo-trunk-ofbiz.apache.org/catalog/control/main?USERNAME=admin&PASSWORD=ofbiz&JavaScriptEnabled=Y
X-Frame-Options header is not included in the HTTP response to protect
against 'ClickJacking' attacks
I have not clear opinion on this one which is only informational. Solution: Most modern Web browsers support the X-Frame-Options HTTP header. Ensure
it's set on all web pages returned by your site (if you expect the page to be framed only by pages on your server (e.g. it's part of a FRAMESET) then
you'll want to use SAMEORIGIN, otherwise if you never expect the page to be framed, you should use DENY. ALLOW-FROM allows specific websites to frame
the web page in supported web browsers).
I'm sorry for the long post, but I thought you might be interested by these results, which are globally positive. Of course I only ran OWASP ZAP in
the simpler mode. If you are interested you might get deeper in this, the tool is amazing!
Jacques
