Thanks for taking care Scott (even if you did not read the full stuff, I guess
you are not alone ;))
Took me some time to answer, for misc. reasons, notably looking into details...
Yes there is a bit more to it...
I totally agree with your point 1. For instance this is dangerous in
ProductSubTabBar
<link target="/ecommerce/control/product" url-mode="inter-app">
OK, I think I will scramble the situation a bit more, and this is not a
security problem, but it will help me to explain.
If you get to
https://demo-stable-ofbiz.apache.org/catalog/control/EditProduct?productId=GZ-1000
and click on the "Product Page" link you will get an error because the ASF front-end/reverse-proxy we use for demos introduces the 18080 port we ask
for (in url.properties) for HTTP links in URLs.
Now weirdly if you get back to
https://demo-stable-ofbiz.apache.org/catalog/control/EditProduct?productId=GZ-1000
and try the link again, it will work. This is because we now put the strict-transport-security header
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#HSTS_mechanism_overview.
So "it" (rather the user's browser) transforms the call to the ecommerce "product" request to a secured request. But there is even a better way, and
it's a simple as that:
ofbizDemo@ofbiz-vm:~/trunk$ svn di
specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/controller.xml
Index: specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/controller.xml
===================================================================
--- specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/controller.xml (revision
1725169)
+++ specialpurpose/ecommerce/webapp/ecommerce/WEB-INF/controller.xml (working
copy)
@@ -860,7 +860,7 @@
<response name="success" type="view" value="category"
save-current-view="true"/>
</request-map>
<request-map uri="product">
- <security https="false" auth="false"/>
+ <security https="true" auth="false"/>
<response name="success" type="view" value="product"
save-current-view="true"/>
</request-map>
<request-map uri="detailImage">
ofbizDemo@ofbiz-vm:~/trunk$
This is why you don't have this issue (link to ecommerce product from catalog)
when looking the same in trunk demo.
For my tests I applied the patch above there (the proxy already gave me some
headaches)
But of course there is an easier way to automate that:
Index: config/url.properties
===================================================================
--- config/url.properties (revision 1725003)
+++ config/url.properties (working copy)
@@ -26,6 +26,7 @@
force.https.host=
# HTTP Port (Not Secure port)
+no.http=Y
port.http=8080
force.http.host=
Index: src/org/ofbiz/webapp/control/ConfigXMLReader.java
===================================================================
--- src/org/ofbiz/webapp/control/ConfigXMLReader.java (revision 1725003)
+++ src/org/ofbiz/webapp/control/ConfigXMLReader.java (working copy)
@@ -41,6 +41,7 @@
import org.ofbiz.base.util.FileUtil;
import org.ofbiz.base.util.GeneralException;
import org.ofbiz.base.util.UtilHttp;
+import org.ofbiz.base.util.UtilProperties;
import org.ofbiz.base.util.UtilValidate;
import org.ofbiz.base.util.UtilXml;
import org.ofbiz.base.util.cache.UtilCache;
@@ -527,7 +528,7 @@
public boolean trackServerHit = true;
public String description;
public Event event;
- public boolean securityHttps = false;
+ public boolean securityHttps = true;
public boolean securityAuth = false;
public boolean securityCert = false;
public boolean securityExternalView = true;
@@ -544,7 +545,9 @@
// Check for security
Element securityElement = UtilXml.firstChildElement(requestMapElement,
"security");
if (securityElement != null) {
- this.securityHttps =
"true".equals(securityElement.getAttribute("https"));
+ if (!UtilProperties.propertyValueEqualsIgnoreCase("url", "no.http",
"Y")) {
+ this.securityHttps =
"true".equals(securityElement.getAttribute("https"));
+ }
this.securityAuth =
"true".equals(securityElement.getAttribute("auth"));
this.securityCert =
"true".equals(securityElement.getAttribute("cert"));
this.securityExternalView =
!"false".equals(securityElement.getAttribute("external-view"));
And this is the change I propose. To not blur things more in this post, I created https://issues.apache.org/jira/browse/OFBIZ-6849 please refer to it
for details.
Also your point 2 is not enough and maybe my 1st post was a bit overwhelming
and certainly not sufficiently clear. So let me try to summarize.
Actually, as http://resources.infosecinstitute.com/cookies-secure-flag-undesired-behavior-modern-browsers, very well explains, if you use HTTP in a
webapp where sessions are also used, a "man in the middle" attack can create a cookie with its own sessionid value and the secure header set. The
attacker can then use this cookie to force his own session in HTTPS mode or force an user to use the attacker's account.
BTW this is detailled in RFC 6265 (section 4.1.2.5), part of it:
<<An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6
<https://tools.ietf.org/html/rfc6265#section-8.6> for more details).>>
part of section 8.6
<<An active network attacker can also inject cookies into the Cookie
header sent tohttps://example.com/ by impersonating a response from
http://example.com/ and injecting a Set-Cookie header. The HTTPS
server at example.com will be unable to distinguish these cookies
from cookies that it set itself in an HTTPS response. An active
network attacker might be able to leverage this ability to mount an
attack against example.com even if example.com uses HTTPS
exclusively.>>
The infosecinstitute article is short enough to be worth reading, at least the
summary :).
This supposes the attacker controls the communication channel, but we should not be sure this will never happen, and quite the opposite, be ready to
face it.
It's a lame comparison but roughly: HTTPS is, for security, similar to what
immutability is for thread-safe. Now let's see why you would want HTTP.
In this article
http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/,
it's said:
<<The real problem, according to Lafon [one of the resident experts on HTTP(s) at the W3C], is that with HTTPS you lose the ability to cache. "Not
really an issue when servers and clients are in the same region (meaning continent)," writes Lafon in an e-mail to Webmonkey, "but people in Australia
(for example) love when something can be cached and served without a huge response time.">> Note that this *from 2011*, but I guess still pertinent.
Most of the time it's not a problem and should not hinder to generalize, moreover as suggested above though default HTTPS would be optional for all
the requests currently not using.
All the other reasons are weak or obsolete, I'll quickly review them in
OFBIZ-6849.
I'm very sorry for the length of this email. I wanted to answer you as concisely as possible, not sure I succeeded. I hope it finally makes sense,
else OFBIZ-6849 an related tasks should.
Jacques
Le 03/01/2016 00:59, Scott Gray a écrit :
I'm too lazy to read all the links but I think we can make some
straightforward changes to improve the situation:
1. Once a user is on https, all links generated should use https
2. If a user is on http, then that's fine and we just need to ensure that
when they switch to https (during login or any other sensitive activities)
that we're able to transfer any existing session information over to a
secure session with a new session id.
Is there any more to it?
Regards
Scott
On 3 January 2016 at 12:14, Jacques Le Roux<jacques.le.r...@les7arts.com>
wrote:
Hi,
You maybe noticed that I began to work on securing and keeping OFBiz
secured better by proposing tools to use and share with the community
https://cwiki.apache.org/confluence/display/OFBIZ/Keeping+OFBiz+secure
This started after I was confronted with the "The 2015 infamous Java
unserialize vulnerability". As explained in the wiki page, there were also
3 other points I wanted to address:
* Java<
https://cwiki.apache.org/confluence/display/OFBIZ/About+OWASP+Dependency+Check
* JavaScript<
https://cwiki.apache.org/confluence/display/OFBIZ/About+retire.js>
* HTTP headers<https://cyh.herokuapp.com/cyh>
I already worked in end of 2013 on updating 3rd party Java lib OFBiz
depends on. It's a tedious work but mostly without surprises, it's only a
matter of rightly upgrading external libs (as much as we can).
I decided to postpone the work on JavaScript libs (it's tedious and mostly
straigthforward as well) because I thought that resolving the issues on
HTTP headers would be much simpler and it was new to me (more fun). So far
I also thought it was a minor point regarding security. I was wrong! OK, it
gets now a bit more complicated, I will try my best to explain in as less
as possible words.
I did not cross much issues, until I began to work on securing cookies. I
committed r1719762 when I decided I should have a look at OFBIZ-6655. I
then reverted r1719762 and tried to commit the proposed patches there, but
finally reverted them because of an issue in ecommerce and reapplied
r1719762. Then Pierre Smits noticed an issue on trunk demo in ecommerce. To
solve it I naively created
https://issues.apache.org/jira/browse/INFRA-10973 and dug the wrong way.
Then Deepak called me because he found an issue with r1719762 and we
decided we should revert, and he did at r1722379 (I did not get a chance
yet to check, but I trust Deepak).
I was writing this email (for few hours) when Scott just wrote
https://issues.apache.org/jira/browse/OFBIZ-6111?focusedCommentId=15076677,
and I agree with him.
But that's not the whole point of this email. While working on securing
cookies, I stumbled upon this blog post
http://resources.infosecinstitute.com/cookies-secure-flag-undesired-behavior-modern-browsers/.
Long story short, you can't have the cake and eat it too. Or rather you
can't use HTTP and be secure if you also use sessions (this is what OFBiz
ecommerce does). I wrote in the title about "Performance over security".
Because the only remaining reason nowadays people would want HTTP is for
performance caching adds.
There is some good articles about that:
http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/
https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything
https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol
To summarize with letsencrypt
https://community.letsencrypt.org/t/frequently-asked-questions-faq
and Server Name Indication
https://en.wikipedia.org/wiki/Server_Name_Indication
https://www.networking4all.com/en/ssl+certificates/faq/server+name+indication/
most of the other concerns are off (we use TLS for a while now in OFBiz)
So I'd like to remove, or rather make optional, HTTP in OFBiz. Though I
did not check technical detail yet, people who really prefer performance
over security would be able to use it through a properties in
url.properties.
You should be interested by
https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
as well
Opinions?
Jacques
PS: nobody knows what really happened to Ian Murdock (it's blurred in
news, I know his family wants discretion)?
