You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Yang Yu <yy...@gmail.com> on 2011/11/16 18:37:43 UTC
Question about IdResolver.getElementById()
In org.apache.xml.security.utils.IdResolver.getElementById(Document doc,
String id), I'm wondering why it's necessary to do a exhaustive search by
calling:
result = IdResolver.getElementBySearching(doc, id);
Do you see any harm if I comment out this line? Because I notice that the
Element is always found by the first call:
Element result = IdResolver.getElementByIdType(doc, id);
Thanks,
Yang
Re: Question about IdResolver.getElementById()
Posted by Yang Yu <yy...@gmail.com>.
I'm not sure if we are talking about the same problem. :) But I think I get
the general idea. Thank you very much for your help, Scott.
On Wed, Nov 16, 2011 at 11:00 AM, Cantor, Scott <ca...@osu.edu> wrote:
> On 11/16/11 1:51 PM, "Yang Yu" <yy...@gmail.com> wrote:
>
> >It's great to know the search will be off by default in the future
> >release. Nasty security problem could happen because of it. Do you know
> >which future release will include this feature?
>
> No, I have nothing to do with the Java development.
>
> For the record, turning it off isn't at all sufficient to prevent those
> security problems. I think they're pretty well intractable in general
> absent very specific scenarios. If you can't sign the whole document, I'd
> be very wary and I certainly wouldn't trust that any code I didn't write
> was correct. Nothing the library can do about it, it's up to the other
> layers.
>
> -- Scott
>
>
Re: Question about IdResolver.getElementById()
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 11/16/11 1:51 PM, "Yang Yu" <yy...@gmail.com> wrote:
>It's great to know the search will be off by default in the future
>release. Nasty security problem could happen because of it. Do you know
>which future release will include this feature?
No, I have nothing to do with the Java development.
For the record, turning it off isn't at all sufficient to prevent those
security problems. I think they're pretty well intractable in general
absent very specific scenarios. If you can't sign the whole document, I'd
be very wary and I certainly wouldn't trust that any code I didn't write
was correct. Nothing the library can do about it, it's up to the other
layers.
-- Scott
Re: Question about IdResolver.getElementById()
Posted by Yang Yu <yy...@gmail.com>.
It's great to know the search will be off by default in the future release.
Nasty security problem could happen because of it. Do you know which future
release will include this feature?
On Wed, Nov 16, 2011 at 10:28 AM, Cantor, Scott <ca...@osu.edu> wrote:
> On 11/16/11 1:08 PM, "Yang Yu" <yy...@gmail.com> wrote:
>
> >Right on the point, Scott. Suppose an application always calls
> >IdResolver.registerElementById() before validating the signature, then
> >the exhaustive search shouldn't be necessary, correct?
>
> It will in general constantly fail unless you have application code
> specifically set up to deal with the problem.
>
> In turn, the IdResolver interface is, I think, an extension point that can
> be used to address that. You can also manually set IDness via DOM3.
>
> Of course, specifics vary. It depends on the application.
>
> >I'm wondering if it's possible to remove the call to
> >IdResolver.getElementBySearching in xml sec library?
>
> I believe it will be an option to disable it, and off by default, in a
> future release.
>
> -- Scott
>
>
Re: Question about IdResolver.getElementById()
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 11/16/11 1:08 PM, "Yang Yu" <yy...@gmail.com> wrote:
>Right on the point, Scott. Suppose an application always calls
>IdResolver.registerElementById() before validating the signature, then
>the exhaustive search shouldn't be necessary, correct?
It will in general constantly fail unless you have application code
specifically set up to deal with the problem.
In turn, the IdResolver interface is, I think, an extension point that can
be used to address that. You can also manually set IDness via DOM3.
Of course, specifics vary. It depends on the application.
>I'm wondering if it's possible to remove the call to
>IdResolver.getElementBySearching in xml sec library?
I believe it will be an option to disable it, and off by default, in a
future release.
-- Scott
Re: Question about IdResolver.getElementById()
Posted by Yang Yu <yy...@gmail.com>.
Right on the point, Scott. Suppose an application always calls
IdResolver.registerElementById() before validating the signature, then the
exhaustive search shouldn't be necessary, correct?
I'm wondering if it's possible to remove the call to
IdResolver.getElementBySearching in xml sec library?
Yang
On Wed, Nov 16, 2011 at 9:41 AM, Cantor, Scott <ca...@osu.edu> wrote:
> On 11/16/11 12:37 PM, "Yang Yu" <yy...@gmail.com> wrote:
>
> >In org.apache.xml.security.utils.IdResolver.getElementById(Document doc,
> >String id), I'm wondering why it's necessary to do a exhaustive search by
> >calling:
> >
> >result = IdResolver.getElementBySearching(doc, id);
> >
> >Do you see any harm if I comment out this line? Because I notice that the
> >Element is always found by the first call:
> >
> >Element result = IdResolver.getElementByIdType(doc, id);
>
> IDness is an extremely complex issue. Unless you have schema validation,
> or extensive content knowledge, you can't know what IDs are present, and
> getElementById won't succeed.
>
> But in turn, searching for Ids is, in general, wrong. It's essentially
> insecure, and if there's still a feature doing that by default, there's a
> bug. The wrapping attacks proved that once and for all (I hope).
>
> -- Scott
>
>
Re: Question about IdResolver.getElementById()
Posted by "Cantor, Scott" <ca...@osu.edu>.
On 11/16/11 12:37 PM, "Yang Yu" <yy...@gmail.com> wrote:
>In org.apache.xml.security.utils.IdResolver.getElementById(Document doc,
>String id), I'm wondering why it's necessary to do a exhaustive search by
>calling:
>
>result = IdResolver.getElementBySearching(doc, id);
>
>Do you see any harm if I comment out this line? Because I notice that the
>Element is always found by the first call:
>
>Element result = IdResolver.getElementByIdType(doc, id);
IDness is an extremely complex issue. Unless you have schema validation,
or extensive content knowledge, you can't know what IDs are present, and
getElementById won't succeed.
But in turn, searching for Ids is, in general, wrong. It's essentially
insecure, and if there's still a feature doing that by default, there's a
bug. The wrapping attacks proved that once and for all (I hope).
-- Scott