ofbiz-dev mailing list archives

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

Mime
View raw message