Re: [VOTE] Create the "security" mailing list for the OFBiz project

2016-07-25 Thread gregory draperi 
On my side I voted +1 as I thing it would be easier for me to follow
security topics with a dedicated list.
Furthermore, I don't need to be added to the private list as I don't
need/want to be part of strategy or main orientations discussions for Ofbiz.


2016-07-25 11:27 GMT+02:00 Scott Gray :

> Why would we do that?  Security concerns are the responsibility of the PMC
> and supposed to be kept confidential until resolved aren't they?
>
> On 25 July 2016 at 20:31, Jacques Le Roux 
> wrote:
>
> > I guess we need at least a separate list to grant access to non
> > OFBiz-PMC/ASF members
> >
> > Jacques
> >
> >
> >
> > Le 25/07/2016 à 06:38, Scott Gray a écrit :
> >
> >> Do we actually need a separate mailing list, or should it just forward
> to
> >> private@?
> >>
> >> Regards
> >> Scott
> >>
> >> On 25 July 2016 at 15:58, Ashish Vijaywargiya <
> >> ashish.vijaywarg...@hotwaxsystems.com> wrote:
> >>
> >> +1
> >>>
> >>> --
> >>> Kind Regards
> >>> Ashish Vijaywargiya
> >>> HotWax Systems - est. 1997
> >>>
> >>>
> >>> On Sun, Jul 24, 2016 at 6:02 PM, Jacopo Cappellato <
> >>> jacopo.cappell...@hotwaxsystems.com> wrote:
> >>>
> >>> Rationale: every ASF project needs a private list to discuss product
>  vulnerabilities; for OFBiz the "private" list has been used for this
>  purpose until now; however an ad-hoc list may be useful because it
> could
>  provide a more focused space to discuss the security issues and could
>  provide more flexibility to invite in the private list persons willing
>  to
>  help that are trusted by the PMC.
> 
>  Please vote,
> 
>  +1
> 
>  to create a "security" list (i.e. secur...@ofbiz.apache.org) and move
> 
> >>> all
> >>>
>  the security related discussions and notifications currently happening
>  on
>  the private list to this new list: according to the ASF policies [*]
> the
>  list will be a private list used by the persons willing to help to
> 
> >>> resolve
> >>>
>  security issues; the list of subscribers will be approved by the OFBiz
> 
> >>> PMC.
> >>>
>  Otherwise vote -1 to continue to use the "private" mailing list for
>  vulnerability handling.
> 
>  [*] http://www.apache.org/security/
> 
> 
> >
>



-- 
Grégory Draperi

Re: [VOTE] Create the "security" mailing list for the OFBiz project

2016-07-24 Thread gregory draperi 
+1

2016-07-24 14:32 GMT+02:00 Jacopo Cappellato <
jacopo.cappell...@hotwaxsystems.com>:

> Rationale: every ASF project needs a private list to discuss product
> vulnerabilities; for OFBiz the "private" list has been used for this
> purpose until now; however an ad-hoc list may be useful because it could
> provide a more focused space to discuss the security issues and could
> provide more flexibility to invite in the private list persons willing to
> help that are trusted by the PMC.
>
> Please vote,
>
> +1
>
> to create a "security" list (i.e. secur...@ofbiz.apache.org) and move all
> the security related discussions and notifications currently happening on
> the private list to this new list: according to the ASF policies [*] the
> list will be a private list used by the persons willing to help to resolve
> security issues; the list of subscribers will be approved by the OFBiz PMC.
>
> Otherwise vote -1 to continue to use the "private" mailing list for
> vulnerability handling.
>
> [*] http://www.apache.org/security/
>



-- 
Grégory Draperi

Re: Token Based Authentication with Apache OfBiz

2016-07-24 Thread gregory draperi 
Hi Jacques,

Okay, so I misunderstood the goal. You can forget what I said :)
Still the article is really interesting :)

Cheers,

Gregory

2016-07-23 12:55 GMT+02:00 Jacques Le Roux <jacques.le.r...@les7arts.com>:

> HI Gregory,
>
> If I'm not mistaken (I'll not do it) the idea is indeed to use tokens for
> one time authentication, but to then use OFBiz current work flow for the
> rest (ie handling sessions)
>
> Quoting below: "Behind the scenes, we will be using the current work flow
> as is"
>
> This is also what we did with the project I spoke about.
>
> Thanks for the article!
>
> Jacques
>
>
>
> Le 22/07/2016 à 15:53, gregory draperi a écrit :
>
>> Hi guys,
>>
>> JSON web tokens are suitable for one time authentication between parties
>> but they have important drawbacks if they are used as a session mechanism
>> (how to store them, not possible to invalidate one...)
>>
>> There is a nice article on this:
>> http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/
>>
>> Best wishes,
>>
>> Gregory
>>
>>
>>
>> 2016-07-13 13:19 GMT+02:00 Rishi Solanki <rishisolan...@gmail.com>:
>>
>> Rahul,
>>>
>>> Thanks for detailed proposal, I gone thru all the details. No changes in
>>> the current auth system, and achieving token based authentication looks a
>>> good idea to me.
>>>
>>> Agree on all the details provided and will try to participate in the
>>> reviewing the design/implementation.
>>>
>>>
>>> +1.
>>>
>>>
>>> Rishi Solanki
>>> Manager, Enterprise Software Development
>>> HotWax Systems Pvt. Ltd.
>>> Direct: +91-9893287847
>>> http://www.hotwaxsystems.com
>>>
>>> On Mon, Jun 20, 2016 at 2:24 AM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> We (I was then working with ilscipio) did something like that for a
>>>> client, and I agree it's the way to go.
>>>>
>>>> I mean that I agree with "We are not going to implement the Token Based
>>>> Authentication process at low level. Behind the scenes, we will be using
>>>> the current work flow as is"
>>>>
>>>> Disclaimer: I did not look into all details. Also we planned to use
>>>>
>>> OpenId
>>>
>>>> but eventually the Token Based Authentication we used was specific and
>>>> proprietary to the client (this remembered me
>>>> http://markmail.org/message/7vtjvjomneimspvl)
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Le 18/06/2016 à 15:01, Rahul Bhooteshwar a écrit :
>>>>
>>>> Hello All,
>>>>> Recently felt the need of Token Based Authentication process in Apache
>>>>> OfBiz while using OfBiz's business process offerings with standalone
>>>>> clients like Mobile Apps, Angular JS based apps running outside Apache
>>>>> OfBiz etc.
>>>>>
>>>>> What currently we are having in OfBiz is session based authentication
>>>>> process which is *stateful*. But while dealing with the independently
>>>>> running remote clients stateful authentication is not gonna work as we
>>>>> will
>>>>> not be using *server-browser session* anymore in those cases.
>>>>>
>>>>> Following are the initial draft & supporting documents to proceed
>>>>>
>>>> further:
>>>
>>>>  - Token Based Authentication in Apache OfBiz
>>>>>  <
>>>>>
>>>>>
>>> https://docs.google.com/document/d/1xbpjNWGZp8B_79YJmPxmSJqkx7Qo_EI7u_PE0WNt3B4/edit#heading=h.g14rrmsoijiv
>>>
>>>>  - Token Based Authentication
>>>>>  <
>>>>>
>>>>>
>>> https://docs.google.com/document/d/15QBV87vMD42QppCaHpxgcefcg_ac7HFeSQQnF_S50nk/edit#heading=h.mdriqalojfy4
>>>
>>>>  - JSON Web Tokens
>>>>>  <
>>>>>
>>>>>
>>> https://docs.google.com/document/d/1wLfv8h_Kkd4iHBxW4Gkx987Q7KBocWAGvss2p4N4fIM/edit
>>>
>>>>  - IETF's  (Internet Engineering Task Force) Documentation for JSON
>>>>>
>>>> Web
>>>
>>>>  Tokens
>>>>>  <
>>>>>
>>>>>
>>> https://drive.google.com/file/d/0BzXOhs4-o0n9cHVGckgwUndsUGc/view?pref=2=1
>>>
>>>> I would like to propose a requirement to implement this in OfBiz, &
>>>>>
>>>> invite
>>>
>>>> you all to provide valuable inputs to conclude the requirements &
>>>>> implementation plans.
>>>>>
>>>>> Thanks and Regards
>>>>> *Rahul Bhooteshwar*
>>>>> Enterprise Software Engineer
>>>>> HotWax Systems <http://www.hotwaxsystems.com/> - *Global leader in
>>>>> innovative enterprise commerce solutions **powered by Apache OFBiz.*
>>>>>
>>>>>
>>>>>
>>
>>
>


-- 
Grégory Draperi

Re: Token Based Authentication with Apache OfBiz

2016-07-22 Thread gregory draperi 
Hi guys,

JSON web tokens are suitable for one time authentication between parties
but they have important drawbacks if they are used as a session mechanism
(how to store them, not possible to invalidate one...)

There is a nice article on this:
http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/

Best wishes,

Gregory



2016-07-13 13:19 GMT+02:00 Rishi Solanki :

> Rahul,
>
> Thanks for detailed proposal, I gone thru all the details. No changes in
> the current auth system, and achieving token based authentication looks a
> good idea to me.
>
> Agree on all the details provided and will try to participate in the
> reviewing the design/implementation.
>
>
> +1.
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Mon, Jun 20, 2016 at 2:24 AM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > We (I was then working with ilscipio) did something like that for a
> > client, and I agree it's the way to go.
> >
> > I mean that I agree with "We are not going to implement the Token Based
> > Authentication process at low level. Behind the scenes, we will be using
> > the current work flow as is"
> >
> > Disclaimer: I did not look into all details. Also we planned to use
> OpenId
> > but eventually the Token Based Authentication we used was specific and
> > proprietary to the client (this remembered me
> > http://markmail.org/message/7vtjvjomneimspvl)
> >
> > Jacques
> >
> >
> >
> > Le 18/06/2016 à 15:01, Rahul Bhooteshwar a écrit :
> >
> >> Hello All,
> >> Recently felt the need of Token Based Authentication process in Apache
> >> OfBiz while using OfBiz's business process offerings with standalone
> >> clients like Mobile Apps, Angular JS based apps running outside Apache
> >> OfBiz etc.
> >>
> >> What currently we are having in OfBiz is session based authentication
> >> process which is *stateful*. But while dealing with the independently
> >> running remote clients stateful authentication is not gonna work as we
> >> will
> >> not be using *server-browser session* anymore in those cases.
> >>
> >> Following are the initial draft & supporting documents to proceed
> further:
> >>
> >> - Token Based Authentication in Apache OfBiz
> >> <
> >>
> https://docs.google.com/document/d/1xbpjNWGZp8B_79YJmPxmSJqkx7Qo_EI7u_PE0WNt3B4/edit#heading=h.g14rrmsoijiv
> >> >
> >> - Token Based Authentication
> >> <
> >>
> https://docs.google.com/document/d/15QBV87vMD42QppCaHpxgcefcg_ac7HFeSQQnF_S50nk/edit#heading=h.mdriqalojfy4
> >> >
> >> - JSON Web Tokens
> >> <
> >>
> https://docs.google.com/document/d/1wLfv8h_Kkd4iHBxW4Gkx987Q7KBocWAGvss2p4N4fIM/edit
> >> >
> >> - IETF's  (Internet Engineering Task Force) Documentation for JSON
> Web
> >> Tokens
> >> <
> >>
> https://drive.google.com/file/d/0BzXOhs4-o0n9cHVGckgwUndsUGc/view?pref=2=1
> >> >
> >>
> >> I would like to propose a requirement to implement this in OfBiz, &
> invite
> >> you all to provide valuable inputs to conclude the requirements &
> >> implementation plans.
> >>
> >> Thanks and Regards
> >> *Rahul Bhooteshwar*
> >> Enterprise Software Engineer
> >> HotWax Systems  - *Global leader in
> >> innovative enterprise commerce solutions **powered by Apache OFBiz.*
> >>
> >>
> >
>



-- 
Grégory Draperi

[jira] [Commented] (OFBIZ-6669) Possible stored XSS issue with Content

2016-04-14 Thread gregory draperi (JIRA) 

[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15241244#comment-15241244
 ] 

gregory draperi commented on OFBIZ-6669:


Hum, there is a problem in my example.

My idea is to still use the html encoder so for example "&" and ">" become & 
and > but then you apply a filter that will look for authorized tags like 

.replaceAll("","")

So you are able to only authorize safe tags.

> Possible stored XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6669.patch, OFBIZ-6669.patch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857  1708930
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858  1708931
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo

[jira] [Commented] (OFBIZ-6669) Possible stored XSS issue with Content

2016-03-11 Thread gregory draperi (JIRA) 

[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190923#comment-15190923
 ] 

gregory draperi commented on OFBIZ-6669:


I wonder if a possible solution would be to encode everything and then decode 
only authorized patterns like:

 becomes bimg//b and then we look and 
replace for authorized patterns
 
"bimg//b".replaceAll("b","")

What do you think?

> Possible stored XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6669.patch, OFBIZ-6669.patch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857  1708930
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858  1708931
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page

[jira] [Commented] (OFBIZ-6669) Possible stored XSS issue with Content

2016-03-11 Thread gregory draperi (JIRA) 

[ 
https://issues.apache.org/jira/browse/OFBIZ-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190918#comment-15190918
 ] 

gregory draperi commented on OFBIZ-6669:


I wonder if a possible solution would be to encode everything and then decode 
only authorized patterns like:

 becomes bimg//b and then we look and 
replace for authorized patterns
 
"bimg//b".replaceAll("b","")

What do you think?

> Possible stored XSS issue with Content
> --
>
> Key: OFBIZ-6669
> URL: https://issues.apache.org/jira/browse/OFBIZ-6669
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, order, party, product, workeffort
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, Upcoming Branch
>
> Attachments: OFBIZ-6669.patch, OFBIZ-6669.patch
>
>
> I found a possible XSS attack through *ContentWrapper.java and ContentWorker 
> itself.
> Note that in supported releases it's hard to exploit, it's a Stored XSS 
> https://www.owasp.org/index.php/Types_of_Cross-Site_Scripting which means you 
> need 1st to somehow inject exploiting code in the DB.
> Issues in *ContentWrapper.java have already been fixed by changing the 
> ContentWrapper interface
> from
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId);
> }
> {code}
> to
> {code}
> public interface ContentWrapper {
> public StringUtil.StringWrapper get(String contentTypeId, String 
> encoderType) {
> }
> {code}
> And changing the Category, Party, Product, ProductPromo, ProductConfigItem 
> and WorkEffort ContentWrapperS accordingly. This means to use 2 types of 
> encoderTypes: "html" and "url".
> The "html"  encoderType will be used for all ProductContentTypes but those 
> who contain URL in their ContentTypeIdS (actually end with, "_URL") which 
> will use "url" encoderType.
> It concerns not only the get() method but also methods like 
> getPartyContentAsText(), getProductContentAsText(), etc.
> It seems a big change but it's straightforward. It's now complete after 
> following commits in revisions (I hope I did not miss to report):
> trunk 1705329 1705417 1705427 1705532 1706159 1706162 1707857  1708930
> and related backports in R14.12 1705331 1705418 1705428 1705533 1706160 
> 1706163 1707858  1708931
> I have also committed a fix for ContentWorker. For that I have added 
> owasp-java-html-sanitizer-r239.jar and put a "content.sanitize=true" property 
> in content.properties with some explanations. The reason I put this property 
> is because the sanitizer does some (safe) changes which might be unwanted in 
> a context where you are "sure" no one can inject/exploit your DB.
> Here is for instance the changes the sanitizer does when rendering cmssite
> {code}
> @@ -19,7 +19,7 @@
>  
> -
> +
>  This is the header!
>  
> @@ -27,34 +27,26 @@
>  
>Welcome to the CmsSite Home page.
> -  
> +
>
>This is a site to demonstrate the CMS capabilities of OFBiz. 
> Its basic function is the editing of website text
>inside a browser. If you want to edit the text you are reading 
> now, logon to the backend system, select the content component
> -  click on 'cmssite' in the website list and ten click on the 
> 'cms' button. There you see on the left hand side the tree of this website.
> -  If you click on 'homepage' then you can edit the content of 
> this page at the box in the r
> +  click on cmssite in the website list and ten click 
> on the cms button. There you see on the left hand side the tree of 
> this website.
> +  If you click on homepage then you can edit the 
> content of this page at the box in the r
>
>
>This is only the basic function of the CMS which is part of 
> the content component. The content component is actually more than a
>CMS it can also handle documents pretty well. An example is 
> the apache OFBiz document you can see when you click on the last option in 
> the list below.
> -  
> -  
> -  
> -Demo Page 1 - 
> Hard Coded Link
> -Demo Page

[jira] [Comment Edited] (OFBIZ-6849) Use only HTTPS in OFBiz

2016-03-11 Thread gregory draperi (JIRA) 

[ 
https://issues.apache.org/jira/browse/OFBIZ-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190762#comment-15190762
 ] 

gregory draperi edited comment on OFBIZ-6849 at 3/11/16 10:20 AM:
--

I share this point of view. For me it makes no sense to have a website in HTTPS 
but the landing page in HTTP since with this configuration you can not ensure 
that the link to the HTTPS has not been modified.


was (Author: gdraperi):
I share this point of view of for it makes no sense to have a website in HTTPS 
but the landing page in HTTP since with this configuration you can not ensure 
that the link to the HTTPS has not been modified.

> Use only HTTPS in OFBiz
> ---
>
> Key: OFBIZ-6849
> URL: https://issues.apache.org/jira/browse/OFBIZ-6849
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6849.patch
>
>
> I recently (~4 weeks ago) started the ["Performance over security, is that 
> reasonable?"|http://markmail.org/message/ubgacfzfxvlvlqva] thread on dev ML. 
> I think I did not explain me well then. I must say it's easy to drown down in 
> details with this subject when you want to illustrate the reasons.
> So instead of only answering on the dev ML, I decided it will be good to 
> create a Jira task with maybe related tasks, here it is.
> For now I consider it only an improvement, but since it's a security matter 
> we can discuss backporting later.
> \\
> 
> h2. TL;DR
> h3. Performance over security?
> So why was this thread opposing performance and security? First we need to 
> understand that here performance stands for HTTP and security for HTTPS.
> h5. Why is HTTP standing for performance?
> Actually is now not much performance difference between the 2 protocols, but 
> you can't cache HTTPS requests and it sometimes (inter-continental requests) 
> matters.
> h3. And why the question about being reasonable or not?
> I think it's unreasonable to put performance over security. And nowadays you 
> are not secure when you use HTTP mixed with HTTPS. Most of the time when you 
> mix both is because you want to identity an user using a sessionId. So with 
> HTTPS, after the user started with HTTP. As concisely explained Forrest in 
> the above referenced thread
> {quote}
> 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.
> {quote}
> It's also well and simply explained (with other things) in [this 
> article|http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/]:
> {quote}
> The HTTP spec defines a “Secure” flag for cookies, which instructs the 
> browser to only send that cookie value over SSL. If sites set that cookie 
> like they’re supposed to, then yes, SSL is helping you out. Most sites don’t, 
> however, and browsers will happily send the sensitive cookies over 
> unencrypted HTTP. Our hypothetical skeezebag really just needs some way to 
> trick you into opening a normal HTTP URL, maybe by e-mailing you a link to 
> http://yourbank.com/a-picture-of-ponies-and-rainbows.gif so he can sniff the 
> plain-text cookie off your unencrypted HTTP request, or by surreptitiously 
> embedding a JavaScript file via some site’s XSS vulnerability.
> {quote}
> Of course if you site is only showing things but nobody has never to 
> identify, then you are not at risk and HTTP only is perfect. But with 
> ecommerce kind of site or such, it's rarely the case, most of the time users 
> need to identify!
> 
> \\
> So why are people still mixing HTTP and HTTPS on their site? In the 1st 
> answer at 
> [\[1\]|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#answer-4376]
>  Thomas Pornin and others gave some interesting points and answers. At 
> [\[2\]|http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/]
>  Yves Lafon gave also a good summary even if a bit old now. I took some 
> questions/answers from 
> [\[3\]|https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything]
>  also. So you might check those links by yourself, here is an abstract:
> # *"Some browsers may not support SSL"* Only old Lynx versions, negligible
> # *"Connection initiation requires some extra network roundtrips"* Negligible 
> but for sites which serve mostly static contents, see &qu

[jira] [Commented] (OFBIZ-6849) Use only HTTPS in OFBiz

2016-03-11 Thread gregory draperi (JIRA) 

[ 
https://issues.apache.org/jira/browse/OFBIZ-6849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190762#comment-15190762
 ] 

gregory draperi commented on OFBIZ-6849:


I share this point of view of for it makes no sense to have a website in HTTPS 
but the landing page in HTTP since with this configuration you can not ensure 
that the link to the HTTPS has not been modified.

> Use only HTTPS in OFBiz
> ---
>
> Key: OFBIZ-6849
> URL: https://issues.apache.org/jira/browse/OFBIZ-6849
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6849.patch
>
>
> I recently (~4 weeks ago) started the ["Performance over security, is that 
> reasonable?"|http://markmail.org/message/ubgacfzfxvlvlqva] thread on dev ML. 
> I think I did not explain me well then. I must say it's easy to drown down in 
> details with this subject when you want to illustrate the reasons.
> So instead of only answering on the dev ML, I decided it will be good to 
> create a Jira task with maybe related tasks, here it is.
> For now I consider it only an improvement, but since it's a security matter 
> we can discuss backporting later.
> \\
> 
> h2. TL;DR
> h3. Performance over security?
> So why was this thread opposing performance and security? First we need to 
> understand that here performance stands for HTTP and security for HTTPS.
> h5. Why is HTTP standing for performance?
> Actually is now not much performance difference between the 2 protocols, but 
> you can't cache HTTPS requests and it sometimes (inter-continental requests) 
> matters.
> h3. And why the question about being reasonable or not?
> I think it's unreasonable to put performance over security. And nowadays you 
> are not secure when you use HTTP mixed with HTTPS. Most of the time when you 
> mix both is because you want to identity an user using a sessionId. So with 
> HTTPS, after the user started with HTTP. As concisely explained Forrest in 
> the above referenced thread
> {quote}
> 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.
> {quote}
> It's also well and simply explained (with other things) in [this 
> article|http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/]:
> {quote}
> The HTTP spec defines a “Secure” flag for cookies, which instructs the 
> browser to only send that cookie value over SSL. If sites set that cookie 
> like they’re supposed to, then yes, SSL is helping you out. Most sites don’t, 
> however, and browsers will happily send the sensitive cookies over 
> unencrypted HTTP. Our hypothetical skeezebag really just needs some way to 
> trick you into opening a normal HTTP URL, maybe by e-mailing you a link to 
> http://yourbank.com/a-picture-of-ponies-and-rainbows.gif so he can sniff the 
> plain-text cookie off your unencrypted HTTP request, or by surreptitiously 
> embedding a JavaScript file via some site’s XSS vulnerability.
> {quote}
> Of course if you site is only showing things but nobody has never to 
> identify, then you are not at risk and HTTP only is perfect. But with 
> ecommerce kind of site or such, it's rarely the case, most of the time users 
> need to identify!
> 
> \\
> So why are people still mixing HTTP and HTTPS on their site? In the 1st 
> answer at 
> [\[1\]|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#answer-4376]
>  Thomas Pornin and others gave some interesting points and answers. At 
> [\[2\]|http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/]
>  Yves Lafon gave also a good summary even if a bit old now. I took some 
> questions/answers from 
> [\[3\]|https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything]
>  also. So you might check those links by yourself, here is an abstract:
> # *"Some browsers may not support SSL"* Only old Lynx versions, negligible
> # *"Connection initiation requires some extra network roundtrips"* Negligible 
> but for sites which serve mostly static contents, see "static content takes a 
> hit" below.
> # *"the SSL initial key exchange adds to the latency"* As [completely 
> explained 
> here|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#comment-6560]:
>  "most TLS se

Re: Welcome to our new committer Gregory Draperi

2016-03-09 Thread gregory draperi 
Hi all,

Thanks for all your nice words.

I hope I will be able to provide some good help regarding application
security.

Best wishes,

Gregory

2016-03-09 8:59 GMT+01:00 Julien NICOLAS :

> Congratulations & welcome aboard Gregory :)
>
> Julien.
>
>
> Le 08/03/2016 17:27, Jacopo Cappellato a écrit :
>
>> Gregory is a software security expert that has been "silently" helping the
>> OFBiz project for years by testing and assessing the security aspects of
>> our system and submitting valuable and precise reports and helping the PMC
>> to resolve them.
>>
>> On behalf of the PMC, welcome onboard Gregory.
>>
>>
>


-- 
Grégory Draperi