Hi Jaques,
thank you for pointing to the OWASP ZAP project and sharing the results
with the the project!
Regards,
Michael
www.ecomify.de
Am 15.01.15 um 11:38 schrieb Jacques Le Roux:
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
