You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Giorgio Zoppi <gi...@gmail.com> on 2020/05/10 09:37:47 UTC
FINERACT-969
Hello Michael,
please assign to me (forgot my jira pass) I have some spare time to mount
OWASP and direct against your host.
As for the Parameters Query, the problem is the implementation itself. It
will make sense to discuss a thinly layer for query separation. In the .NET
world we have Dapper. https://github.com/StackExchange/Dapper used in
StackOverflow. I dont know if there is
a similar stuff in Java.
I see the real meat is still old fineract, instead the fineract-cn is still
work in progress. So i will install the old one.
Best Regards,
Giorgio.
Re: FINERACT-969
Posted by Giorgio Zoppi <gi...@gmail.com>.
Hi Micheal,
>So the work that Manthan will be doing in
https://issues.apache.org/jira/browse/FINERACT-854 hopefully will help to
avoid that future Fineract developers craft queries by String
concatenation, and address the possible SQL injection security
vulnerability - >in a pragmatic way that normally we are able to easily
achieve really soon (next 2-3 weeks already, I'm hoping).
This is good!
> What you are suggesting re. https://github.com/speedment/speedment looks
> "interesting" purely from a technical framework PoV, but probably isn't
> "required" for security (after FINERACT-854), but is more of a general new
> approach / framework? But you don't have to ask if you can open JIRA
> tickets, it's OK to just go ahead and create tickets. But it does of course
> raise the question of what the value of adding yet another framework and
> way of doing SQL queries in Fineract is... if you are interested in
> innovating in this space, nobody should be able to stop you, it's open
> source! If you asked me if I thought adding a new query framework was a top
> priority for the project, my answer probably would be some polite variation
> of "not so sure"... ;-) Hope this helps? Again, I think this isn't really
> related to pentesting in FINERACT-969.
>
Yes. It is not related. It was in the middle of the discussion, I will
concentrate on zap proxy.
> I have started using Java Streams, most of the read is happening over the
>> sql native calls because of complex relationship defined.
>>
>> Speedmentn streams are nice.
>>
>>>
>>>
>>>> FYI we have a GSoC student who is going to work on
>>>> https://issues.apache.org/jira/browse/FINERACT-854 and
>>>> https://issues.apache.org/jira/browse/FINERACT-853. I would expect
>>>> that certain of the issues your work on FINERACT-969 will uncover will be
>>>> fixed by FINERACT-854.
>>>>
>>>> If I were you, I would not wait for that work to complete, but instead
>>>> go ahead, create JIRA bugs for everything you identify (best as sub-tasks
>>>> under FINERACT-962, perhaps?) - and then later help us verify that the
>>>> FINERACT-854 work actually fixed (some.. and which) of what you'll find.
>>>> Makes sense?
>>>>
>>> Yes, glad to help
>>>
>>
I will await after FINERACT-853.
BR,
Giorgio.
Re: FINERACT-969
Posted by Michael Vorburger <mi...@vorburger.ch>.
On Sun, May 10, 2020 at 4:41 PM Saransh Sharma <sa...@muellners.com>
wrote:
> On Sun, 10 May 2020, 20:01 Giorgio Zoppi, <gi...@gmail.com> wrote:
>
>>
>> El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<mi...@vorburger.ch>)
>> escribió:
>>
>>> Buongiorno (?) Giorgio!
>>>
>>
>> Buongiorno Micheal,
>> I have attached the report in the JIRA, i will take further investigation
>> later against the old UI app.
>>
>>>
>>> Cool! We're excited to see you explore
>>> https://issues.apache.org/jira/browse/FINERACT-969.
>>>
>>
>>
>>>
>>>
>>>> As for the Parameters Query, the problem is the implementation itself.
>>>> It will make sense to discuss a thinly layer for query separation. In the
>>>> .NET world we have Dapper. https://github.com/StackExchange/Dapper used
>>>> in StackOverflow. I dont know if there is a similar stuff in Java.
>>>>
>>> There are many, out there some are really cool.
>
>>
>>> I'm not 100% sure what you mean, but I believe you may be making the
>>> point that the use of an ORM (Object Relational Mapping) framework can help
>>> prevent SQL Injection. I agree with this! FYI Fineract already uses one (
>>> https://openjpa.apache.org, but note
>>> https://issues.apache.org/jira/browse/FINERACT-849 for potentially
>>> possibly maybe switching). Fineract only uses ORM for write. Much read is
>>> still direct SQL.
>>>
>>> It was related to ORM, but in more general to get all queries in a place
>> and using Java Streams, the renderer will take care of doing paramtetric
>> query for example:
>> https://github.com/speedment/speedment . So you avoid that your student
>> crafts queries
>>
> We kind of have to develop the framework approach rather then queries
> written as usual.
>
>> concatenating strings but use just java streams . Does sense to open a
>> jira ticket for that?
>>
>
So the work that Manthan will be doing in
https://issues.apache.org/jira/browse/FINERACT-854 hopefully will help to
avoid that future Fineract developers craft queries by String
concatenation, and address the possible SQL injection security
vulnerability - in a pragmatic way that normally we are able to easily
achieve really soon (next 2-3 weeks already, I'm hoping).
What you are suggesting re. https://github.com/speedment/speedment looks
"interesting" purely from a technical framework PoV, but probably isn't
"required" for security (after FINERACT-854), but is more of a general new
approach / framework? But you don't have to ask if you can open JIRA
tickets, it's OK to just go ahead and create tickets. But it does of course
raise the question of what the value of adding yet another framework and
way of doing SQL queries in Fineract is... if you are interested in
innovating in this space, nobody should be able to stop you, it's open
source! If you asked me if I thought adding a new query framework was a top
priority for the project, my answer probably would be some polite variation
of "not so sure"... ;-) Hope this helps? Again, I think this isn't really
related to pentesting in FINERACT-969.
> I have started using Java Streams, most of the read is happening over the
> sql native calls because of complex relationship defined.
>
> Speedmentn streams are nice.
>
>>
>>
>>> FYI we have a GSoC student who is going to work on
>>> https://issues.apache.org/jira/browse/FINERACT-854 and
>>> https://issues.apache.org/jira/browse/FINERACT-853. I would expect that
>>> certain of the issues your work on FINERACT-969 will uncover will be fixed
>>> by FINERACT-854.
>>>
>>> If I were you, I would not wait for that work to complete, but instead
>>> go ahead, create JIRA bugs for everything you identify (best as sub-tasks
>>> under FINERACT-962, perhaps?) - and then later help us verify that the
>>> FINERACT-854 work actually fixed (some.. and which) of what you'll find.
>>> Makes sense?
>>>
>> Yes, glad to help.
>>
>>>
>>>
>>>> I see the real meat is still old fineract, instead the fineract-cn is
>>>> still work in progress. So i will install the old one.
>>>>
>>>
>>> Contributions to both are obviously always very welcome... :_)
>>>
>> My idea about fineract-cn is that it doesn't make sense to craft in Java
>> (i am sorry). It is too verbose for doing microservices, i would prefer
>> another platform as .NET or Go. I don't see much work on cn yet.
>>
> Whole idea of the microservices is to allow any platform written in any
> language. But at present this seems like a barrier.
>
>
Thanks for your amazing work in fineract.dev,
>>
>
Thank you for your feedback, appreciate it; glad you like it!
it would be nice if some expert will prepare an appliance to be used in
>> virtualbox. So it will speed up the testing and learning about fineract.
>>
>
I think our current answer for speeding up the testing and learning about
fineract locally now is to just use
https://github.com/apache/fineract/#instructions-to-run-using-docker-and-docker-compose
- are you aware of and perhaps already had a chance to try that? I'm
personally not sure what value producing a VirtualBox image would add... In
2020 it's more about Containers than VMs? ;-)
> Best Regards,
>> Giorgio
>>
>
Re: FINERACT-969
Posted by Saransh Sharma <sa...@muellners.com>.
On Sun, 10 May 2020, 20:01 Giorgio Zoppi, <gi...@gmail.com> wrote:
>
> El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<mi...@vorburger.ch>)
> escribió:
>
>> Buongiorno (?) Giorgio!
>>
>
> Buongiorno Micheal,
> I have attached the report in the JIRA, i will take further investigation
> later against the old UI app.
>
>>
>> Cool! We're excited to see you explore
>> https://issues.apache.org/jira/browse/FINERACT-969.
>>
>
>
>>
>>
>>> As for the Parameters Query, the problem is the implementation itself.
>>> It will make sense to discuss a thinly layer for query separation. In the
>>> .NET world we have Dapper. https://github.com/StackExchange/Dapper used
>>> in StackOverflow. I dont know if there is a similar stuff in Java.
>>>
>> There are many, out there some are really cool.
>
>> I'm not 100% sure what you mean, but I believe you may be making the
>> point that the use of an ORM (Object Relational Mapping) framework can help
>> prevent SQL Injection. I agree with this! FYI Fineract already uses one (
>> https://openjpa.apache.org, but note
>> https://issues.apache.org/jira/browse/FINERACT-849 for potentially
>> possibly maybe switching). Fineract only uses ORM for write. Much read is
>> still direct SQL.
>>
>> It was related to ORM, but in more general to get all queries in a place
> and using Java Streams, the renderer will take care of doing paramtetric
> query for example:
> https://github.com/speedment/speedment . So you avoid that your student
> crafts queries
>
We kind of have to develop the framework approach rather then queries
written as usual.
> concatenating strings but use just java streams . Does sense to open a
> jira ticket for that?
>
I have started using Java Streams, most of the read is happening over the
sql native calls because of complex relationship defined.
Speedmentn streams are nice.
>
>
>> FYI we have a GSoC student who is going to work on
>> https://issues.apache.org/jira/browse/FINERACT-854 and
>> https://issues.apache.org/jira/browse/FINERACT-853. I would expect that
>> certain of the issues your work on FINERACT-969 will uncover will be fixed
>> by FINERACT-854.
>>
>> If I were you, I would not wait for that work to complete, but instead go
>> ahead, create JIRA bugs for everything you identify (best as sub-tasks
>> under FINERACT-962, perhaps?) - and then later help us verify that the
>> FINERACT-854 work actually fixed (some.. and which) of what you'll find.
>> Makes sense?
>>
> Yes, glad to help.
>
>>
>>
>>> I see the real meat is still old fineract, instead the fineract-cn is
>>> still work in progress. So i will install the old one.
>>>
>>
>> Contributions to both are obviously always very welcome... :_)
>>
> My idea about fineract-cn is that it doesn't make sense to craft in Java
> (i am sorry). It is too verbose for doing microservices, i would prefer
> another platform as .NET or Go. I don't see much work on cn yet.
>
Whole idea of the microservices is to allow any platform written in any
language. But at present this seems like a barrier.
Thanks for your amazing work in fineract.dev, it would be nice if some
> expert will prepare an appliance to be used in virtualbox. So it will speed
> up the testing and learning about fineract.
>
> Best Regards,
> Giorgio
>
Re: FINERACT-969
Posted by Giorgio Zoppi <gi...@gmail.com>.
El dom., 10 may. 2020 a las 14:22, Michael Vorburger (<mi...@vorburger.ch>)
escribió:
> Buongiorno (?) Giorgio!
>
Buongiorno Micheal,
I have attached the report in the JIRA, i will take further investigation
later against the old UI app.
>
> Cool! We're excited to see you explore
> https://issues.apache.org/jira/browse/FINERACT-969.
>
>
>
>> As for the Parameters Query, the problem is the implementation itself. It
>> will make sense to discuss a thinly layer for query separation. In the .NET
>> world we have Dapper. https://github.com/StackExchange/Dapper used in
>> StackOverflow. I dont know if there is a similar stuff in Java.
>>
>
> I'm not 100% sure what you mean, but I believe you may be making the point
> that the use of an ORM (Object Relational Mapping) framework can help
> prevent SQL Injection. I agree with this! FYI Fineract already uses one (
> https://openjpa.apache.org, but note
> https://issues.apache.org/jira/browse/FINERACT-849 for potentially
> possibly maybe switching). Fineract only uses ORM for write. Much read is
> still direct SQL.
>
> It was related to ORM, but in more general to get all queries in a place
and using Java Streams, the renderer will take care of doing paramtetric
query for example:
https://github.com/speedment/speedment . So you avoid that your student
crafts queries concatenating strings but use just java streams . Does sense
to open a jira ticket for that?
> FYI we have a GSoC student who is going to work on
> https://issues.apache.org/jira/browse/FINERACT-854 and
> https://issues.apache.org/jira/browse/FINERACT-853. I would expect that
> certain of the issues your work on FINERACT-969 will uncover will be fixed
> by FINERACT-854.
>
> If I were you, I would not wait for that work to complete, but instead go
> ahead, create JIRA bugs for everything you identify (best as sub-tasks
> under FINERACT-962, perhaps?) - and then later help us verify that the
> FINERACT-854 work actually fixed (some.. and which) of what you'll find.
> Makes sense?
>
Yes, glad to help.
>
>
>> I see the real meat is still old fineract, instead the fineract-cn is
>> still work in progress. So i will install the old one.
>>
>
> Contributions to both are obviously always very welcome... :_)
>
My idea about fineract-cn is that it doesn't make sense to craft in Java (i
am sorry). It is too verbose for doing microservices, i would prefer
another platform as .NET or Go. I don't see much work on cn yet.
Thanks for your amazing work in fineract.dev, it would be nice if some
expert will prepare an appliance to be used in virtualbox. So it will speed
up the testing and learning about fineract.
Best Regards,
Giorgio
Re: FINERACT-969
Posted by Michael Vorburger <mi...@vorburger.ch>.
Buongiorno (?) Giorgio!
On Sun, May 10, 2020 at 11:38 AM Giorgio Zoppi <gi...@gmail.com>
wrote:
> Hello Michael,
> please assign to me (forgot my jira pass) I have some spare time to mount
> OWASP and direct against your host.
>
BTW I've just granted you the require JIRA permission so that you can
assign issues to yourself in the future.
Cool! We're excited to see you explore
https://issues.apache.org/jira/browse/FINERACT-969.
If anyone else reading along here is into this sort of stuff, we also
welcome eyes helping to comb through, and raise PRs to address, what
https://jira.apache.org/jira/browse/FINERACT-967 identifies. I expect some
of it will naturally overlap with what Giorgio finds in FINERACT-969 -
that's fine.
PS if you forgot your JIRA password, you should be able to easily reset it
yourself via email.
> As for the Parameters Query, the problem is the implementation itself. It
> will make sense to discuss a thinly layer for query separation. In the .NET
> world we have Dapper. https://github.com/StackExchange/Dapper used in
> StackOverflow. I dont know if there is a similar stuff in Java.
>
I'm not 100% sure what you mean, but I believe you may be making the point
that the use of an ORM (Object Relational Mapping) framework can help
prevent SQL Injection. I agree with this! FYI Fineract already uses one (
https://openjpa.apache.org, but note
https://issues.apache.org/jira/browse/FINERACT-849 for potentially possibly
maybe switching). Fineract only uses ORM for write. Much read is still
direct SQL.
FYI we have a GSoC student who is going to work on
https://issues.apache.org/jira/browse/FINERACT-854 and
https://issues.apache.org/jira/browse/FINERACT-853. I would expect that
certain of the issues your work on FINERACT-969 will uncover will be fixed
by FINERACT-854.
If I were you, I would not wait for that work to complete, but instead go
ahead, create JIRA bugs for everything you identify (best as sub-tasks
under FINERACT-962, perhaps?) - and then later help us verify that the
FINERACT-854 work actually fixed (some.. and which) of what you'll find.
Makes sense?
> I see the real meat is still old fineract, instead the fineract-cn is
> still work in progress. So i will install the old one.
>
Contributions to both are obviously always very welcome... :_)
> Best Regards,
> Giorgio.
>
Best,
M.
_______________________
Michael Vorburger
http://www.vorburger.ch