Performance over security, is that reasonable?
Locked
Performance over security, is that reasonable?
 
Administrator
|
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)? |
Re: Performance over security, is that reasonable?
|
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 <[hidden email]> 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)? > > |
Re: Performance over security, is that reasonable?
|
|
It needs to be HTTPS all the time, or HTTPS none of the time.
One of the properties of a TLS connection is data integrity. That is, you know if data is changed in transit. This is the mechanism that prevents a person on the network between you and the server to change your traffic, man-in-the-middle as I'm sure everyone has heard or knows about. If you're switching between HTTPS and HTTP based on some criteria, an attacker can leverage that to trick the user into all kind of things. Including changing all the embedded HTTPS URLs sent to the user's browser during a switch from HTTP to HTTPS, back to HTTP. Chrome would throw up all kinds of warnings about this fortunately. Secondly, you're then putting the burden of security on the person authoring the request-map to define that criteria for switching. Frankly, if you're operating any web application that handles PII on the Internet, and not using HTTPS, you're putting all your users at risk, and you need to change that. There is a great tool for quickly checking the basic security controls that can be enabled for web servers, take a look at my site: https://securityheaders.io/?q=https%3A%2F%2Fpartner.fidelissd.com%2F&hide=on -Forrest On 1/2/16 3:59 PM, Scott Gray wrote: > 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 <[hidden email]> > 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)? >> >> |
Re: Performance over security, is that reasonable?
|
Administrator
|
Thanks for your interest and your support Forrest.
15 days ago I start to write a detailed answer to yours Scott. But I got sidetracked and it's not yet finished. I will try to finish this weekend, even if not totally complete. Jacques Le 16/01/2016 19:31, Forrest Rae a écrit : > It needs to be HTTPS all the time, or HTTPS none of the time. > > One of the properties of a TLS connection is data integrity. That is, you know if data is changed in transit. This is the mechanism that prevents > a person on the network between you and the server to change your traffic, man-in-the-middle as I'm sure everyone has heard or knows about. If > you're switching between HTTPS and HTTP based on some criteria, an attacker can leverage that to trick the user into all kind of things. Including > changing all the embedded HTTPS URLs sent to the user's browser during a switch from HTTP to HTTPS, back to HTTP. Chrome would throw up all kinds > of warnings about this fortunately. > > Secondly, you're then putting the burden of security on the person authoring the request-map to define that criteria for switching. > > Frankly, if you're operating any web application that handles PII on the Internet, and not using HTTPS, you're putting all your users at risk, and > you need to change that. > > There is a great tool for quickly checking the basic security controls that can be enabled for web servers, take a look at my site: > https://securityheaders.io/?q=https%3A%2F%2Fpartner.fidelissd.com%2F&hide=on > > -Forrest > > On 1/2/16 3:59 PM, Scott Gray wrote: >> 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 <[hidden email]> >> 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)? >>> >>> > > |
Re: Performance over security, is that reasonable?
|
Administrator
|
In reply to this post by Scott Gray-3
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<[hidden email]> > 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)? >> >> |
Re: Performance over security, is that reasonable?
|
|
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 <[hidden email]> 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<[hidden email]> >> 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)? >>> >>> >>> > |
Re: Performance over security, is that reasonable?
|
|
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 <[hidden email]> 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 <[hidden email] > > 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<[hidden email] >>> > >>> 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)? >>>> >>>> >>>> >> > |
Re: Performance over security, is that reasonable?
|
Administrator
|
In reply to this post by Scott Gray-3
Le 25/01/2016 21:08, Scott Gray a écrit : > I'm not sure why you included that stuff about the demo server, it didn't > seem relevant. Yes, It's only relevant to introduce the solution I propose to always have HTTPS request. I wrote this 1 week ago and was reluctant to send it because I found some issues with my solution. I still believe it's the simplest, versatile and most efficient way, and I have opened OFBIZ-6849 to work on it. Also Ron's explanation is brilliant and concise > 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." The problem is the man in the middle has access to HTTP before and can then build a fake session inside a created new cookie Anyway, I'll now answer to your 2nd message Jacques > > 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 <[hidden email]> > 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<[hidden email]> >>> 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)? >>>> >>>> >>>> |
Re: Performance over security, is that reasonable?
|
Administrator
|
In reply to this post by Scott Gray-3
Le 25/01/2016 21:26, Scott Gray a écrit :
> 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 Actually, as Ron explained, we need to use only HTTPS or only HTTP. I will try to convince you :) Note: that HTTP only is only good for sites where you don't identify users > 2. Generate a new session when they switch to HTTPS This is not enough as I tried to explain > 3. Generate a new session when they login Still the man in the middle possibility, because of open HTTP provided Jacques > > > > On 26 January 2016 at 09:08, Scott Gray <[hidden email]> > 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 <[hidden email] >>> 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<[hidden email] >>>> 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)? >>>>> >>>>> >>>>> |
Re: Performance over security, is that reasonable?
|
Administrator
|
In reply to this post by Jacques Le Roux
Le 26/01/2016 12:05, Jacques Le Roux a écrit :
> > > Le 25/01/2016 21:08, Scott Gray a écrit : >> I'm not sure why you included that stuff about the demo server, it didn't >> seem relevant. > > Yes, It's only relevant to introduce the solution I propose to always have HTTPS request. > I wrote this 1 week ago and was reluctant to send it because I found some issues with my solution. > I still believe it's the simplest, versatile and most efficient way, and I have opened OFBIZ-6849 to work on it. > > Also Ron's explanation is brilliant and concise Sorry for the confusion, it was Forrest Rae, not Ron :/ Jacques > >> 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." > > The problem is the man in the middle has access to HTTP before and can then build a fake session inside a created new cookie > > Anyway, I'll now answer to your 2nd message > > Jacques > >> >> 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 <[hidden email]> >> 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<[hidden email]> >>>> 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)? >>>>> >>>>> >>>>> > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |