I'm not sure why you included that stuff about the demo server, it didn't seem relevant.
Regarding your doubts on #2, in the first article you linked to, I point you to this sentence: "This attack will work, provided that there is no session regeneration in the application after successful login." Suggestion #2 specifically stated that we should regenerate the session when the user switches to HTTPS. The user or attacker can provide any token they like during HTTP but it will never become the HTTPS session. Regards Scott On 26 January 2016 at 03:57, Jacques Le Roux <jacques.le.r...@les7arts.com> 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)? >>> >>> >>> >
