Actually upon reflection, I think I see the vulnerability. We'd need to do a third thing if we don't it already: 1. Once a user is on HTTPS they must be kept on HTTPS 2. Generate a new session when they switch to HTTPS 3. Generate a new session when they login
On 26 January 2016 at 09:08, Scott Gray <scott.g...@hotwaxsystems.com> wrote: > 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)? >>>> >>>> >>>> >> >
