You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@isis.apache.org by matias nahuel heredia <ma...@informaticos.com> on 2014/07/29 03:28:58 UTC
ApacheISIS Vulnerability Bad Object Filter
hi Dan!!
how can i fix this vulnerability in Apache isis?
https://www.youtube.com/watch?v=AghmbcVE710
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 3 September 2014 22:13, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
wrote:
> Hi to all.
>
> I see REALLY great work made on the new Authentication and Authorization
> module on the Isis AddOns Github repository at [1].
>
> It's the most cool impelmentation of a "generic" RBAC "domain" (in the DDD
> sense) I've seen ready for integrating, so it's a really powerful weapon
> for all us.
>
> Thanks!!
>
glad you like it!
>
> By the fact, my only doubt is how two conflicting permissions inherited
> from different roles acquire prevalence. Normally, the more restrictive one
> takes precedence (i.e., if any role "VETOES" - in the security add-on
> terminology -) access to any feature - property, collection or action - it
> should take precedence.
>
> I could easily refactor so that the algorithm for comparing permissions is
factored out to a substitutable domain service.
>
> Also on [2] I don't find also any "priority" if any conflict is found on
> permissions.
>
>
OK, is that a common design... to have a priority and use the permission
with the highest number to resolve conflicts? I guess that makes sense.
Even so, there would still be the need to deal with a two permissions that
have the same priority, so a substitutable algorithm would still be needed,
I think?
Gonna work on this today, so let me know your preferences.
Cheers
Dan
> Any help on it ?
>
> Thanks again !!!
>
> Oscar
>
>
> [1] https://github.com/isisaddons/isis-module-security
>
> [2]
> https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/permission/ApplicationPermissions.java
>
>
> El 31/07/2014, a las 09:00, GESCONSULTOR - Óscar Bou <
> o.bou@gesconsultor.com> escribió:
>
> Really nice to hear!
>
> It will be extremely useful for most projects and a great differentiator
> for any other dev platforms out there.
>
> Thanks, Jeroen! If you want to contrast any thoughts, test concepts, etc.
> this August I will have a "bit more" time outside of our current project.
>
>
> Regards,
>
> Oscar
>
>
> El 31/07/2014, a las 08:44, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
> Jeroen has started implementing said RBAC module, and we also have a
> related requirement to support multi-tenancy... ie we need a domain concept
> of "User" somewhere, which is in its own subdomain but that an be managed
> through Isis itself.
>
> Intention is to make this a deliverable, in some form, for 1.7.0; as you
> said, Oscar, there was a lot of interest in this at IsisCon.
>
> Cheers
> Dan
>
>
>
> On 31 July 2014 07:41, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
> wrote:
>
>>
>> Hi to all.
>>
>> I think Dan's proposal is the best implementation possible, as it would
>> not be embedded on the Domain, which would imply that could, for example,
>> being configured by an admin through a UI.
>>
>> This is related with an Isis Authorization module we talked about on
>> IsisCon, considering things like a RBAC style (see [1], [2] for Shiro
>> related materials; [3] [4] for RBAC generic introduction).
>>
>> Nearly all business applications will "suffer" for implementing this
>> requisite, so it's a good candidate for a generic Isis module.
>>
>> Thanks,
>>
>> Oscar
>>
>> [1]
>> https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html
>>
>> [2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html
>>
>> [3] http://csrc.nist.gov/groups/SNS/rbac/
>>
>> [4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
>>
>>
>>
>> El 30/07/2014, a las 23:37, Dan Haywood <da...@haywood-associates.co.uk>
>> escribió:
>>
>>
>> Hmm, not particularly keen on this suggestion... having role names
>> embedded
>> in annotations isn't a good idea, I think.
>>
>> For myself, I'd rather that this requirement was handled in a
>> cross-cutting
>> fashoin, through some sort of extension to the Isis' authorizor API.
>>
>> However, to solve this issue properly, I think we might need to extend
>> Isis' security model somewhat. Right now in the authorizor we check if a
>> given user (via their roles) can view/use each of an object's members
>> (properties/collections/actions) but we don't have the concept of checking
>> if the user can view the object at all.
>>
>> If we did introduce this idea (of object-level checks), then we could also
>> implement some sort of plug-in point for the authorizor such that
>> instance-based authorizers (eg in a chain of responsibility pattern) could
>> be added to supplement Isis' usual class-based authorizors.
>>
>> I know this design would work because the Naked Objects "sister project"
>> (on .NET) works this way.
>>
>> Hopefully that makes some sort of sense.... thoughts, anyone?
>>
>> Dan
>>
>>
>>
>>
>> On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
>> wrote:
>>
>> El 29/07/14 08:16, Dan Haywood escribió:
>>
>> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>>
>> wrote:
>>
>> hi Dan!!
>>
>> how can i fix this vulnerability in Apache isis?
>> https://www.youtube.com/watch?v=AghmbcVE710
>>
>>
>> thanks for recording this, helps explain the issue.
>>
>> What we're talking about here is per-instance security... the idea that
>> some users shouldn't be able to access some object instances (even though
>> they do in general have access to other instances of a given class type,
>> such as ToDoItem).
>>
>> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
>> callback (on ToDoItem itself) and have it thrown an exception if the
>> object
>> should not be accessible. Then, the ExceptionRecognizer can be used to
>> translate this exception into a user-friendly error message. If the
>> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
>> then this is already detected by the default implementation of
>> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
>> rJdoObjectStore):
>>
>>
>> final String ownedBy = getOwnedBy();
>> final String currentUser = container.getUser().getName();
>> if(!ownedBy.equals(currentUser)) {
>> throw new JDOObjectNotFoundException("No such object");
>> }
>>
>>
>> This code results in a redirect to the error page with a message: "Unable
>> to load object. Has it been deleted by someone else? No such object".
>> The "Unable to load object. Has it been deleted by someone else?" bit
>> comes
>> from the ExceptionRecognizer, the "No such object" comes from the loaded()
>> method.
>>
>> I can think of two improvements.
>>
>> First, it would be to move this cross-cutting concern out of the entity
>> (ToDoItem) and into some single subscriber that could do this sort of
>> verification for all classes. We do have a ticket [1] to do this, I'll
>> bring it forward to tackle in the next release 1.7.0.
>>
>> Second, the stack trace shown by Isis is rather ugly and also leaks the
>> information that there is an object with the given identifier (even if the
>> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
>> become more sophisticated such that the stack trace will be suppressed in
>> some cases.
>>
>> I've raised a ticket for this requirement [2], citing this thread [3]
>>
>> Let me know your thoughts on the above.
>>
>> Thanks
>> Dan
>>
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-803
>> [2] https://issues.apache.org/jira/browse/ISIS-846
>>
>> i think the better way to validate this is the creation of metanotation
>>
>> in the Framework
>> like that
>> @forUser(name="getOwnedBy",allfor="role1,role2")
>> public class NameClass
>> {
>>
>>
>> }
>>
>>
>>
>> Óscar Bou Bou
>> Responsable de Producto
>> Auditor Jefe de Certificación ISO 27001 en BSI
>> CISA, CRISC, APMG ISO 20000, ITIL-F
>>
>> <contactenos.html.gif> 902 900 231 / 620 267 520
>> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>>
>> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>>
>> <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>>
>> <gesconsultor_logo_blue_email.png>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos
>> contienen información reservada que no puede ser difundida. Si usted ha
>> recibido este correo por error, tenga la amabilidad de eliminarlo de su
>> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
>> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>> Su dirección de correo electrónico junto a sus datos personales constan
>> en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la
>> de mantener el contacto con Ud. Si quiere saber de qué información
>> disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo
>> enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a
>> la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana,
>> 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015
>> (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o
>> sus archivos adjuntos no contengan virus informáticos, y en caso que los
>> tuvieran eliminarlos.
>>
>>
>>
>>
>>
>>
>
>
> *Óscar Bou Bou*
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> <contactenos.html.gif> 902 900 231 / 620 267 520
> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>
> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>
> <blog.png> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
> <gesconsultor_logo_blue_email.png>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
>
> *Óscar Bou Bou*
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi to all.
I see REALLY great work made on the new Authentication and Authorization module on the Isis AddOns Github repository at [1].
It's the most cool impelmentation of a "generic" RBAC "domain" (in the DDD sense) I've seen ready for integrating, so it's a really powerful weapon for all us.
Thanks!!
On current ToDo example application, the concept of "user" was a business domain concept, and not a "security domain" concept, so it wouldn't force any security measures, which was Matias main objection.
By using new capabilities on the new isis-module-security addon it can be fully integrated with Shiro, becoming not a "business domain" concept but a "security domain" entity.
By the fact, my only doubt is how two conflicting permissions inherited from different roles acquire prevalence. Normally, the more restrictive one takes precedence (i.e., if any role "VETOES" - in the security add-on terminology -) access to any feature - property, collection or action - it should take precedence.
However, I don't see any reference on the (greatly detailed) documentation at [1].
Also on [2] I don't find also any "priority" if any conflict is found on permissions.
Any help on it ?
Thanks again !!!
Oscar
[1] https://github.com/isisaddons/isis-module-security
[2] https://github.com/isisaddons/isis-module-security/blob/master/dom/src/main/java/org/isisaddons/module/security/dom/permission/ApplicationPermissions.java
El 31/07/2014, a las 09:00, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> escribió:
> Really nice to hear!
>
> It will be extremely useful for most projects and a great differentiator for any other dev platforms out there.
>
> Thanks, Jeroen! If you want to contrast any thoughts, test concepts, etc. this August I will have a "bit more" time outside of our current project.
>
>
> Regards,
>
> Oscar
>
>
> El 31/07/2014, a las 08:44, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>> Jeroen has started implementing said RBAC module, and we also have a related requirement to support multi-tenancy... ie we need a domain concept of "User" somewhere, which is in its own subdomain but that an be managed through Isis itself.
>>
>> Intention is to make this a deliverable, in some form, for 1.7.0; as you said, Oscar, there was a lot of interest in this at IsisCon.
>>
>> Cheers
>> Dan
>>
>>
>>
>> On 31 July 2014 07:41, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>>
>> Hi to all.
>>
>> I think Dan's proposal is the best implementation possible, as it would not be embedded on the Domain, which would imply that could, for example, being configured by an admin through a UI.
>>
>> This is related with an Isis Authorization module we talked about on IsisCon, considering things like a RBAC style (see [1], [2] for Shiro related materials; [3] [4] for RBAC generic introduction).
>>
>> Nearly all business applications will "suffer" for implementing this requisite, so it's a good candidate for a generic Isis module.
>>
>> Thanks,
>>
>> Oscar
>>
>> [1] https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html
>>
>> [2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html
>>
>> [3] http://csrc.nist.gov/groups/SNS/rbac/
>>
>> [4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
>>
>>
>>
>> El 30/07/2014, a las 23:37, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>>
>>
>>> Hmm, not particularly keen on this suggestion... having role names embedded
>>> in annotations isn't a good idea, I think.
>>>
>>> For myself, I'd rather that this requirement was handled in a cross-cutting
>>> fashoin, through some sort of extension to the Isis' authorizor API.
>>>
>>> However, to solve this issue properly, I think we might need to extend
>>> Isis' security model somewhat. Right now in the authorizor we check if a
>>> given user (via their roles) can view/use each of an object's members
>>> (properties/collections/actions) but we don't have the concept of checking
>>> if the user can view the object at all.
>>>
>>> If we did introduce this idea (of object-level checks), then we could also
>>> implement some sort of plug-in point for the authorizor such that
>>> instance-based authorizers (eg in a chain of responsibility pattern) could
>>> be added to supplement Isis' usual class-based authorizors.
>>>
>>> I know this design would work because the Naked Objects "sister project"
>>> (on .NET) works this way.
>>>
>>> Hopefully that makes some sort of sense.... thoughts, anyone?
>>>
>>> Dan
>>>
>>>
>>>
>>>
>>> On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
>>> wrote:
>>>
>>>> El 29/07/14 08:16, Dan Haywood escribió:
>>>>
>>>> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>>>>> wrote:
>>>>>
>>>>> hi Dan!!
>>>>>> how can i fix this vulnerability in Apache isis?
>>>>>> https://www.youtube.com/watch?v=AghmbcVE710
>>>>>>
>>>>>>
>>>>> thanks for recording this, helps explain the issue.
>>>>>
>>>>> What we're talking about here is per-instance security... the idea that
>>>>> some users shouldn't be able to access some object instances (even though
>>>>> they do in general have access to other instances of a given class type,
>>>>> such as ToDoItem).
>>>>>
>>>>> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
>>>>> callback (on ToDoItem itself) and have it thrown an exception if the
>>>>> object
>>>>> should not be accessible. Then, the ExceptionRecognizer can be used to
>>>>> translate this exception into a user-friendly error message. If the
>>>>> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
>>>>> then this is already detected by the default implementation of
>>>>> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
>>>>> rJdoObjectStore):
>>>>>
>>>>>
>>>>> final String ownedBy = getOwnedBy();
>>>>> final String currentUser = container.getUser().getName();
>>>>> if(!ownedBy.equals(currentUser)) {
>>>>> throw new JDOObjectNotFoundException("No such object");
>>>>> }
>>>>>
>>>>>
>>>>> This code results in a redirect to the error page with a message: "Unable
>>>>> to load object. Has it been deleted by someone else? No such object".
>>>>> The "Unable to load object. Has it been deleted by someone else?" bit
>>>>> comes
>>>>> from the ExceptionRecognizer, the "No such object" comes from the loaded()
>>>>> method.
>>>>>
>>>>> I can think of two improvements.
>>>>>
>>>>> First, it would be to move this cross-cutting concern out of the entity
>>>>> (ToDoItem) and into some single subscriber that could do this sort of
>>>>> verification for all classes. We do have a ticket [1] to do this, I'll
>>>>> bring it forward to tackle in the next release 1.7.0.
>>>>>
>>>>> Second, the stack trace shown by Isis is rather ugly and also leaks the
>>>>> information that there is an object with the given identifier (even if the
>>>>> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
>>>>> become more sophisticated such that the stack trace will be suppressed in
>>>>> some cases.
>>>>>
>>>>> I've raised a ticket for this requirement [2], citing this thread [3]
>>>>>
>>>>> Let me know your thoughts on the above.
>>>>>
>>>>> Thanks
>>>>> Dan
>>>>>
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/ISIS-803
>>>>> [2] https://issues.apache.org/jira/browse/ISIS-846
>>>>>
>>>>> i think the better way to validate this is the creation of metanotation
>>>> in the Framework
>>>> like that
>>>> @forUser(name="getOwnedBy",allfor="role1,role2")
>>>> public class NameClass
>>>> {
>>>>
>>>>
>>>> }
>>>>
>>
>>
>> Óscar Bou Bou
>> Responsable de Producto
>> Auditor Jefe de Certificación ISO 27001 en BSI
>> CISA, CRISC, APMG ISO 20000, ITIL-F
>>
>> <contactenos.html.gif> 902 900 231 / 620 267 520
>> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>>
>> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>>
>> <blog.png> http://www.GesConsultor.com
>>
>> <gesconsultor_logo_blue_email.png>
>>
>>
>> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
>> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>>
>>
>>
>>
>>
>>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> <contactenos.html.gif> 902 900 231 / 620 267 520
> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>
> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>
> <blog.png> http://www.GesConsultor.com
>
> <gesconsultor_logo_blue_email.png>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>
>
>
>
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Really nice to hear!
It will be extremely useful for most projects and a great differentiator for any other dev platforms out there.
Thanks, Jeroen! If you want to contrast any thoughts, test concepts, etc. this August I will have a "bit more" time outside of our current project.
Regards,
Oscar
El 31/07/2014, a las 08:44, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> Jeroen has started implementing said RBAC module, and we also have a related requirement to support multi-tenancy... ie we need a domain concept of "User" somewhere, which is in its own subdomain but that an be managed through Isis itself.
>
> Intention is to make this a deliverable, in some form, for 1.7.0; as you said, Oscar, there was a lot of interest in this at IsisCon.
>
> Cheers
> Dan
>
>
>
> On 31 July 2014 07:41, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com> wrote:
>
> Hi to all.
>
> I think Dan's proposal is the best implementation possible, as it would not be embedded on the Domain, which would imply that could, for example, being configured by an admin through a UI.
>
> This is related with an Isis Authorization module we talked about on IsisCon, considering things like a RBAC style (see [1], [2] for Shiro related materials; [3] [4] for RBAC generic introduction).
>
> Nearly all business applications will "suffer" for implementing this requisite, so it's a good candidate for a generic Isis module.
>
> Thanks,
>
> Oscar
>
> [1] https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html
>
> [2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html
>
> [3] http://csrc.nist.gov/groups/SNS/rbac/
>
> [4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
>
>
>
> El 30/07/2014, a las 23:37, Dan Haywood <da...@haywood-associates.co.uk> escribió:
>
>
>> Hmm, not particularly keen on this suggestion... having role names embedded
>> in annotations isn't a good idea, I think.
>>
>> For myself, I'd rather that this requirement was handled in a cross-cutting
>> fashoin, through some sort of extension to the Isis' authorizor API.
>>
>> However, to solve this issue properly, I think we might need to extend
>> Isis' security model somewhat. Right now in the authorizor we check if a
>> given user (via their roles) can view/use each of an object's members
>> (properties/collections/actions) but we don't have the concept of checking
>> if the user can view the object at all.
>>
>> If we did introduce this idea (of object-level checks), then we could also
>> implement some sort of plug-in point for the authorizor such that
>> instance-based authorizers (eg in a chain of responsibility pattern) could
>> be added to supplement Isis' usual class-based authorizors.
>>
>> I know this design would work because the Naked Objects "sister project"
>> (on .NET) works this way.
>>
>> Hopefully that makes some sort of sense.... thoughts, anyone?
>>
>> Dan
>>
>>
>>
>>
>> On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
>> wrote:
>>
>>> El 29/07/14 08:16, Dan Haywood escribió:
>>>
>>> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>>>> wrote:
>>>>
>>>> hi Dan!!
>>>>> how can i fix this vulnerability in Apache isis?
>>>>> https://www.youtube.com/watch?v=AghmbcVE710
>>>>>
>>>>>
>>>> thanks for recording this, helps explain the issue.
>>>>
>>>> What we're talking about here is per-instance security... the idea that
>>>> some users shouldn't be able to access some object instances (even though
>>>> they do in general have access to other instances of a given class type,
>>>> such as ToDoItem).
>>>>
>>>> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
>>>> callback (on ToDoItem itself) and have it thrown an exception if the
>>>> object
>>>> should not be accessible. Then, the ExceptionRecognizer can be used to
>>>> translate this exception into a user-friendly error message. If the
>>>> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
>>>> then this is already detected by the default implementation of
>>>> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
>>>> rJdoObjectStore):
>>>>
>>>>
>>>> final String ownedBy = getOwnedBy();
>>>> final String currentUser = container.getUser().getName();
>>>> if(!ownedBy.equals(currentUser)) {
>>>> throw new JDOObjectNotFoundException("No such object");
>>>> }
>>>>
>>>>
>>>> This code results in a redirect to the error page with a message: "Unable
>>>> to load object. Has it been deleted by someone else? No such object".
>>>> The "Unable to load object. Has it been deleted by someone else?" bit
>>>> comes
>>>> from the ExceptionRecognizer, the "No such object" comes from the loaded()
>>>> method.
>>>>
>>>> I can think of two improvements.
>>>>
>>>> First, it would be to move this cross-cutting concern out of the entity
>>>> (ToDoItem) and into some single subscriber that could do this sort of
>>>> verification for all classes. We do have a ticket [1] to do this, I'll
>>>> bring it forward to tackle in the next release 1.7.0.
>>>>
>>>> Second, the stack trace shown by Isis is rather ugly and also leaks the
>>>> information that there is an object with the given identifier (even if the
>>>> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
>>>> become more sophisticated such that the stack trace will be suppressed in
>>>> some cases.
>>>>
>>>> I've raised a ticket for this requirement [2], citing this thread [3]
>>>>
>>>> Let me know your thoughts on the above.
>>>>
>>>> Thanks
>>>> Dan
>>>>
>>>>
>>>> [1] https://issues.apache.org/jira/browse/ISIS-803
>>>> [2] https://issues.apache.org/jira/browse/ISIS-846
>>>>
>>>> i think the better way to validate this is the creation of metanotation
>>> in the Framework
>>> like that
>>> @forUser(name="getOwnedBy",allfor="role1,role2")
>>> public class NameClass
>>> {
>>>
>>>
>>> }
>>>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> <contactenos.html.gif> 902 900 231 / 620 267 520
> <Pasted Graphic 1.tiff> http://www.twitter.com/oscarbou
>
> <gesdatos-software.gif> http://es.linkedin.com/in/oscarbou
>
> <blog.png> http://www.GesConsultor.com
>
> <gesconsultor_logo_blue_email.png>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
>
>
>
>
>
>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Jeroen has started implementing said RBAC module, and we also have a
related requirement to support multi-tenancy... ie we need a domain concept
of "User" somewhere, which is in its own subdomain but that an be managed
through Isis itself.
Intention is to make this a deliverable, in some form, for 1.7.0; as you
said, Oscar, there was a lot of interest in this at IsisCon.
Cheers
Dan
On 31 July 2014 07:41, GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>
wrote:
>
> Hi to all.
>
> I think Dan's proposal is the best implementation possible, as it would
> not be embedded on the Domain, which would imply that could, for example,
> being configured by an admin through a UI.
>
> This is related with an Isis Authorization module we talked about on
> IsisCon, considering things like a RBAC style (see [1], [2] for Shiro
> related materials; [3] [4] for RBAC generic introduction).
>
> Nearly all business applications will "suffer" for implementing this
> requisite, so it's a good candidate for a generic Isis module.
>
> Thanks,
>
> Oscar
>
> [1]
> https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html
>
> [2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html
>
> [3] http://csrc.nist.gov/groups/SNS/rbac/
>
> [4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
>
>
>
> El 30/07/2014, a las 23:37, Dan Haywood <da...@haywood-associates.co.uk>
> escribió:
>
>
> Hmm, not particularly keen on this suggestion... having role names embedded
> in annotations isn't a good idea, I think.
>
> For myself, I'd rather that this requirement was handled in a cross-cutting
> fashoin, through some sort of extension to the Isis' authorizor API.
>
> However, to solve this issue properly, I think we might need to extend
> Isis' security model somewhat. Right now in the authorizor we check if a
> given user (via their roles) can view/use each of an object's members
> (properties/collections/actions) but we don't have the concept of checking
> if the user can view the object at all.
>
> If we did introduce this idea (of object-level checks), then we could also
> implement some sort of plug-in point for the authorizor such that
> instance-based authorizers (eg in a chain of responsibility pattern) could
> be added to supplement Isis' usual class-based authorizors.
>
> I know this design would work because the Naked Objects "sister project"
> (on .NET) works this way.
>
> Hopefully that makes some sort of sense.... thoughts, anyone?
>
> Dan
>
>
>
>
> On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
> wrote:
>
> El 29/07/14 08:16, Dan Haywood escribió:
>
> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>
> wrote:
>
> hi Dan!!
>
> how can i fix this vulnerability in Apache isis?
> https://www.youtube.com/watch?v=AghmbcVE710
>
>
> thanks for recording this, helps explain the issue.
>
> What we're talking about here is per-instance security... the idea that
> some users shouldn't be able to access some object instances (even though
> they do in general have access to other instances of a given class type,
> such as ToDoItem).
>
> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
> callback (on ToDoItem itself) and have it thrown an exception if the
> object
> should not be accessible. Then, the ExceptionRecognizer can be used to
> translate this exception into a user-friendly error message. If the
> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
> then this is already detected by the default implementation of
> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
> rJdoObjectStore):
>
>
> final String ownedBy = getOwnedBy();
> final String currentUser = container.getUser().getName();
> if(!ownedBy.equals(currentUser)) {
> throw new JDOObjectNotFoundException("No such object");
> }
>
>
> This code results in a redirect to the error page with a message: "Unable
> to load object. Has it been deleted by someone else? No such object".
> The "Unable to load object. Has it been deleted by someone else?" bit
> comes
> from the ExceptionRecognizer, the "No such object" comes from the loaded()
> method.
>
> I can think of two improvements.
>
> First, it would be to move this cross-cutting concern out of the entity
> (ToDoItem) and into some single subscriber that could do this sort of
> verification for all classes. We do have a ticket [1] to do this, I'll
> bring it forward to tackle in the next release 1.7.0.
>
> Second, the stack trace shown by Isis is rather ugly and also leaks the
> information that there is an object with the given identifier (even if the
> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
> become more sophisticated such that the stack trace will be suppressed in
> some cases.
>
> I've raised a ticket for this requirement [2], citing this thread [3]
>
> Let me know your thoughts on the above.
>
> Thanks
> Dan
>
>
> [1] https://issues.apache.org/jira/browse/ISIS-803
> [2] https://issues.apache.org/jira/browse/ISIS-846
>
> i think the better way to validate this is the creation of metanotation
>
> in the Framework
> like that
> @forUser(name="getOwnedBy",allfor="role1,role2")
> public class NameClass
> {
>
>
> }
>
>
>
> Óscar Bou Bou
> Responsable de Producto
> Auditor Jefe de Certificación ISO 27001 en BSI
> CISA, CRISC, APMG ISO 20000, ITIL-F
>
> 902 900 231 / 620 267 520
> http://www.twitter.com/oscarbou
>
> http://es.linkedin.com/in/oscarbou
>
> http://www.GesConsultor.com <http://www.gesconsultor.com/>
>
>
>
> Este mensaje y los ficheros anexos son confidenciales. Los mismos
> contienen información reservada que no puede ser difundida. Si usted ha
> recibido este correo por error, tenga la amabilidad de eliminarlo de su
> sistema y avisar al remitente mediante reenvío a su dirección electrónica;
> no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
> Su dirección de correo electrónico junto a sus datos personales constan en
> un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de
> mantener el contacto con Ud. Si quiere saber de qué información disponemos
> de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un
> escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente
> dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo -
> 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia).
> Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos
> adjuntos no contengan virus informáticos, y en caso que los tuvieran
> eliminarlos.
>
>
>
>
>
>
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by GESCONSULTOR - Óscar Bou <o....@gesconsultor.com>.
Hi to all.
I think Dan's proposal is the best implementation possible, as it would not be embedded on the Domain, which would imply that could, for example, being configured by an admin through a UI.
This is related with an Isis Authorization module we talked about on IsisCon, considering things like a RBAC style (see [1], [2] for Shiro related materials; [3] [4] for RBAC generic introduction).
Nearly all business applications will "suffer" for implementing this requisite, so it's a good candidate for a generic Isis module.
Thanks,
Oscar
[1] https://shiro.apache.org/2011/05/24/the-new-rbac-resource-based-access-control.html
[2] http://sangeeth.github.com/java/shiro/rbac-using-shiro.html
[3] http://csrc.nist.gov/groups/SNS/rbac/
[4] http://csrc.nist.gov/rbac/sandhu-ferraiolo-kuhn-00.pdf
El 30/07/2014, a las 23:37, Dan Haywood <da...@haywood-associates.co.uk> escribió:
> Hmm, not particularly keen on this suggestion... having role names embedded
> in annotations isn't a good idea, I think.
>
> For myself, I'd rather that this requirement was handled in a cross-cutting
> fashoin, through some sort of extension to the Isis' authorizor API.
>
> However, to solve this issue properly, I think we might need to extend
> Isis' security model somewhat. Right now in the authorizor we check if a
> given user (via their roles) can view/use each of an object's members
> (properties/collections/actions) but we don't have the concept of checking
> if the user can view the object at all.
>
> If we did introduce this idea (of object-level checks), then we could also
> implement some sort of plug-in point for the authorizor such that
> instance-based authorizers (eg in a chain of responsibility pattern) could
> be added to supplement Isis' usual class-based authorizors.
>
> I know this design would work because the Naked Objects "sister project"
> (on .NET) works this way.
>
> Hopefully that makes some sort of sense.... thoughts, anyone?
>
> Dan
>
>
>
>
> On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
> wrote:
>
>> El 29/07/14 08:16, Dan Haywood escribió:
>>
>> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>>> wrote:
>>>
>>> hi Dan!!
>>>> how can i fix this vulnerability in Apache isis?
>>>> https://www.youtube.com/watch?v=AghmbcVE710
>>>>
>>>>
>>> thanks for recording this, helps explain the issue.
>>>
>>> What we're talking about here is per-instance security... the idea that
>>> some users shouldn't be able to access some object instances (even though
>>> they do in general have access to other instances of a given class type,
>>> such as ToDoItem).
>>>
>>> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
>>> callback (on ToDoItem itself) and have it thrown an exception if the
>>> object
>>> should not be accessible. Then, the ExceptionRecognizer can be used to
>>> translate this exception into a user-friendly error message. If the
>>> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
>>> then this is already detected by the default implementation of
>>> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
>>> rJdoObjectStore):
>>>
>>>
>>> final String ownedBy = getOwnedBy();
>>> final String currentUser = container.getUser().getName();
>>> if(!ownedBy.equals(currentUser)) {
>>> throw new JDOObjectNotFoundException("No such object");
>>> }
>>>
>>>
>>> This code results in a redirect to the error page with a message: "Unable
>>> to load object. Has it been deleted by someone else? No such object".
>>> The "Unable to load object. Has it been deleted by someone else?" bit
>>> comes
>>> from the ExceptionRecognizer, the "No such object" comes from the loaded()
>>> method.
>>>
>>> I can think of two improvements.
>>>
>>> First, it would be to move this cross-cutting concern out of the entity
>>> (ToDoItem) and into some single subscriber that could do this sort of
>>> verification for all classes. We do have a ticket [1] to do this, I'll
>>> bring it forward to tackle in the next release 1.7.0.
>>>
>>> Second, the stack trace shown by Isis is rather ugly and also leaks the
>>> information that there is an object with the given identifier (even if the
>>> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
>>> become more sophisticated such that the stack trace will be suppressed in
>>> some cases.
>>>
>>> I've raised a ticket for this requirement [2], citing this thread [3]
>>>
>>> Let me know your thoughts on the above.
>>>
>>> Thanks
>>> Dan
>>>
>>>
>>> [1] https://issues.apache.org/jira/browse/ISIS-803
>>> [2] https://issues.apache.org/jira/browse/ISIS-846
>>>
>>> i think the better way to validate this is the creation of metanotation
>> in the Framework
>> like that
>> @forUser(name="getOwnedBy",allfor="role1,role2")
>> public class NameClass
>> {
>>
>>
>> }
>>
Óscar Bou Bou
Responsable de Producto
Auditor Jefe de Certificación ISO 27001 en BSI
CISA, CRISC, APMG ISO 20000, ITIL-F
902 900 231 / 620 267 520
http://www.twitter.com/oscarbou
http://es.linkedin.com/in/oscarbou
http://www.GesConsultor.com
Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona.
Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hmm, not particularly keen on this suggestion... having role names embedded
in annotations isn't a good idea, I think.
For myself, I'd rather that this requirement was handled in a cross-cutting
fashoin, through some sort of extension to the Isis' authorizor API.
However, to solve this issue properly, I think we might need to extend
Isis' security model somewhat. Right now in the authorizor we check if a
given user (via their roles) can view/use each of an object's members
(properties/collections/actions) but we don't have the concept of checking
if the user can view the object at all.
If we did introduce this idea (of object-level checks), then we could also
implement some sort of plug-in point for the authorizor such that
instance-based authorizers (eg in a chain of responsibility pattern) could
be added to supplement Isis' usual class-based authorizors.
I know this design would work because the Naked Objects "sister project"
(on .NET) works this way.
Hopefully that makes some sort of sense.... thoughts, anyone?
Dan
On 29 July 2014 22:56, matias nahuel heredia <ma...@informaticos.com>
wrote:
> El 29/07/14 08:16, Dan Haywood escribió:
>
> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
>> wrote:
>>
>> hi Dan!!
>>> how can i fix this vulnerability in Apache isis?
>>> https://www.youtube.com/watch?v=AghmbcVE710
>>>
>>>
>> thanks for recording this, helps explain the issue.
>>
>> What we're talking about here is per-instance security... the idea that
>> some users shouldn't be able to access some object instances (even though
>> they do in general have access to other instances of a given class type,
>> such as ToDoItem).
>>
>> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
>> callback (on ToDoItem itself) and have it thrown an exception if the
>> object
>> should not be accessible. Then, the ExceptionRecognizer can be used to
>> translate this exception into a user-friendly error message. If the
>> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
>> then this is already detected by the default implementation of
>> ExceptionRecognizer (namely ExceptionRecognizerCompositeFo
>> rJdoObjectStore):
>>
>>
>> final String ownedBy = getOwnedBy();
>> final String currentUser = container.getUser().getName();
>> if(!ownedBy.equals(currentUser)) {
>> throw new JDOObjectNotFoundException("No such object");
>> }
>>
>>
>> This code results in a redirect to the error page with a message: "Unable
>> to load object. Has it been deleted by someone else? No such object".
>> The "Unable to load object. Has it been deleted by someone else?" bit
>> comes
>> from the ExceptionRecognizer, the "No such object" comes from the loaded()
>> method.
>>
>> I can think of two improvements.
>>
>> First, it would be to move this cross-cutting concern out of the entity
>> (ToDoItem) and into some single subscriber that could do this sort of
>> verification for all classes. We do have a ticket [1] to do this, I'll
>> bring it forward to tackle in the next release 1.7.0.
>>
>> Second, the stack trace shown by Isis is rather ugly and also leaks the
>> information that there is an object with the given identifier (even if the
>> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
>> become more sophisticated such that the stack trace will be suppressed in
>> some cases.
>>
>> I've raised a ticket for this requirement [2], citing this thread [3]
>>
>> Let me know your thoughts on the above.
>>
>> Thanks
>> Dan
>>
>>
>> [1] https://issues.apache.org/jira/browse/ISIS-803
>> [2] https://issues.apache.org/jira/browse/ISIS-846
>>
>> i think the better way to validate this is the creation of metanotation
> in the Framework
> like that
> @forUser(name="getOwnedBy",allfor="role1,role2")
> public class NameClass
> {
>
>
> }
>
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by matias nahuel heredia <ma...@informaticos.com>.
El 29/07/14 08:16, Dan Haywood escribió:
> On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
> wrote:
>
>> hi Dan!!
>> how can i fix this vulnerability in Apache isis?
>> https://www.youtube.com/watch?v=AghmbcVE710
>>
>
> thanks for recording this, helps explain the issue.
>
> What we're talking about here is per-instance security... the idea that
> some users shouldn't be able to access some object instances (even though
> they do in general have access to other instances of a given class type,
> such as ToDoItem).
>
> As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
> callback (on ToDoItem itself) and have it thrown an exception if the object
> should not be accessible. Then, the ExceptionRecognizer can be used to
> translate this exception into a user-friendly error message. If the
> loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
> then this is already detected by the default implementation of
> ExceptionRecognizer (namely ExceptionRecognizerCompositeForJdoObjectStore):
>
>
> final String ownedBy = getOwnedBy();
> final String currentUser = container.getUser().getName();
> if(!ownedBy.equals(currentUser)) {
> throw new JDOObjectNotFoundException("No such object");
> }
>
>
> This code results in a redirect to the error page with a message: "Unable
> to load object. Has it been deleted by someone else? No such object".
> The "Unable to load object. Has it been deleted by someone else?" bit comes
> from the ExceptionRecognizer, the "No such object" comes from the loaded()
> method.
>
> I can think of two improvements.
>
> First, it would be to move this cross-cutting concern out of the entity
> (ToDoItem) and into some single subscriber that could do this sort of
> verification for all classes. We do have a ticket [1] to do this, I'll
> bring it forward to tackle in the next release 1.7.0.
>
> Second, the stack trace shown by Isis is rather ugly and also leaks the
> information that there is an object with the given identifier (even if the
> object itself isn't shown). So perhaps the ExceptionRecognizer needs to
> become more sophisticated such that the stack trace will be suppressed in
> some cases.
>
> I've raised a ticket for this requirement [2], citing this thread [3]
>
> Let me know your thoughts on the above.
>
> Thanks
> Dan
>
>
> [1] https://issues.apache.org/jira/browse/ISIS-803
> [2] https://issues.apache.org/jira/browse/ISIS-846
>
i think the better way to validate this is the creation of metanotation
in the Framework
like that
@forUser(name="getOwnedBy",allfor="role1,role2")
public class NameClass
{
}
Re: ApacheISIS Vulnerability Bad Object Filter
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
On 29 July 2014 02:28, matias nahuel heredia <ma...@informaticos.com>
wrote:
> hi Dan!!
> how can i fix this vulnerability in Apache isis?
> https://www.youtube.com/watch?v=AghmbcVE710
>
thanks for recording this, helps explain the issue.
What we're talking about here is per-instance security... the idea that
some users shouldn't be able to access some object instances (even though
they do in general have access to other instances of a given class type,
such as ToDoItem).
As of Isis 1.6.0, the best I can suggest is to use the loaded() lifecycle
callback (on ToDoItem itself) and have it thrown an exception if the object
should not be accessible. Then, the ExceptionRecognizer can be used to
translate this exception into a user-friendly error message. If the
loaded() lifecycle callback throws the javax.jdo.ObjectNotFoundException
then this is already detected by the default implementation of
ExceptionRecognizer (namely ExceptionRecognizerCompositeForJdoObjectStore):
final String ownedBy = getOwnedBy();
final String currentUser = container.getUser().getName();
if(!ownedBy.equals(currentUser)) {
throw new JDOObjectNotFoundException("No such object");
}
This code results in a redirect to the error page with a message: "Unable
to load object. Has it been deleted by someone else? No such object".
The "Unable to load object. Has it been deleted by someone else?" bit comes
from the ExceptionRecognizer, the "No such object" comes from the loaded()
method.
I can think of two improvements.
First, it would be to move this cross-cutting concern out of the entity
(ToDoItem) and into some single subscriber that could do this sort of
verification for all classes. We do have a ticket [1] to do this, I'll
bring it forward to tackle in the next release 1.7.0.
Second, the stack trace shown by Isis is rather ugly and also leaks the
information that there is an object with the given identifier (even if the
object itself isn't shown). So perhaps the ExceptionRecognizer needs to
become more sophisticated such that the stack trace will be suppressed in
some cases.
I've raised a ticket for this requirement [2], citing this thread [3]
Let me know your thoughts on the above.
Thanks
Dan
[1] https://issues.apache.org/jira/browse/ISIS-803
[2] https://issues.apache.org/jira/browse/ISIS-846