wrote:
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)?
