You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by "Ottinger, Joseph" <jo...@techtarget.com> on 2006/10/05 18:12:44 UTC
Security problem with QueryManager?
I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right?
When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'";
Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst.
Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole.
Am I missing something?
Re: Security problem with QueryManager?
Posted by Michael Neale <mi...@gmail.com>.
yes if you are really concerned, then use a custom AccessManager - nothing
escapes its view - which is where it differs from JDBC.
Having said that, a prepared statement or other convenient "builder" style
interface would be really nice for queries. As powerful and terse as xpath
is, I find it slightly confusing to use.
On 10/6/06, Stefan Guggisberg <st...@gmail.com> wrote:
>
> On 10/6/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> > Ah ha! That's definitely better than I was afraid of... but how does one
> go about configuring this properly? (Any documentation for mere mortals
> anywhere?)
> >
>
> jsr-170 (JCR 1.x) does not cover access control management, i.e. assigning
> and managing access rights is vendor-specific.
>
> jsr-283 (JCR 2.x) will probably cover access control management by
> defining
> a standard api for managing access rights.
>
> jackrabbit supports pluggable custom access control through the
> AccessControlManager interface. currently there's only a dummy
> implementation
> available in jackrabbit, so you'd have to roll your own.
>
> cheers
> stefan
>
> > ________________________________
> >
> > From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> > Sent: Fri 10/6/2006 5:52 AM
> > To: users@jackrabbit.apache.org
> > Subject: Re: Security problem with QueryManager?
> >
> >
> >
> > On 10/5/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> > > I was playing around with JCR's query facility and realised something
> a little scary. Perhaps I'm just ignorant, but... hey, that's why I email
> the list, right?
> > >
> > > When I build SQL queries, I do something like this: "select * from
> nt:unstructured where foo='"+bar+"'";
> > >
> > > Oh, wait. If I was actually using JDBC, I'd *never* do this, because
> some fool out there will try to set bar to something that will return more
> than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every
> node will be returned. Application error at best, exposure of sensitive data
> at worst.
> > >
> > > Then I thought, well, hey, I have XPath, right? But in XPath, I can
> construct a query the same way. Hello, security hole.
> > >
> > > Am I missing something?
> >
> > well, unlike databases JCR *does* provide fine-grained access control,
> i.e. the
> > user will only get those results which he has read-access on.
> >
> > cheers
> > stefan
> >
> > >
> >
> >
> >
> >
>
Re: Security problem with QueryManager?
Posted by Stefan Guggisberg <st...@gmail.com>.
On 10/6/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> Ah ha! That's definitely better than I was afraid of... but how does one go about configuring this properly? (Any documentation for mere mortals anywhere?)
>
jsr-170 (JCR 1.x) does not cover access control management, i.e. assigning
and managing access rights is vendor-specific.
jsr-283 (JCR 2.x) will probably cover access control management by defining
a standard api for managing access rights.
jackrabbit supports pluggable custom access control through the
AccessControlManager interface. currently there's only a dummy implementation
available in jackrabbit, so you'd have to roll your own.
cheers
stefan
> ________________________________
>
> From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> Sent: Fri 10/6/2006 5:52 AM
> To: users@jackrabbit.apache.org
> Subject: Re: Security problem with QueryManager?
>
>
>
> On 10/5/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> > I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right?
> >
> > When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'";
> >
> > Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst.
> >
> > Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole.
> >
> > Am I missing something?
>
> well, unlike databases JCR *does* provide fine-grained access control, i.e. the
> user will only get those results which he has read-access on.
>
> cheers
> stefan
>
> >
>
>
>
>
RE: Security problem with QueryManager?
Posted by "Ottinger, Joseph" <jo...@techtarget.com>.
Ah ha! That's definitely better than I was afraid of... but how does one go about configuring this properly? (Any documentation for mere mortals anywhere?)
________________________________
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: Fri 10/6/2006 5:52 AM
To: users@jackrabbit.apache.org
Subject: Re: Security problem with QueryManager?
On 10/5/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right?
>
> When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'";
>
> Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst.
>
> Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole.
>
> Am I missing something?
well, unlike databases JCR *does* provide fine-grained access control, i.e. the
user will only get those results which he has read-access on.
cheers
stefan
>
Re: Security problem with QueryManager?
Posted by Stefan Guggisberg <st...@gmail.com>.
On 10/5/06, Ottinger, Joseph <jo...@techtarget.com> wrote:
> I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right?
>
> When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'";
>
> Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst.
>
> Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole.
>
> Am I missing something?
well, unlike databases JCR *does* provide fine-grained access control, i.e. the
user will only get those results which he has read-access on.
cheers
stefan
>
Re: Security problem with QueryManager?
Posted by Paul J DeCoursey <pa...@decoursey.net>.
You are missing the convenience of the PreparedStatement... you will
have to do your own data validation.
Ottinger, Joseph wrote:
> I was playing around with JCR's query facility and realised something a little scary. Perhaps I'm just ignorant, but... hey, that's why I email the list, right?
>
> When I build SQL queries, I do something like this: "select * from nt:unstructured where foo='"+bar+"'";
>
> Oh, wait. If I was actually using JDBC, I'd *never* do this, because some fool out there will try to set bar to something that will return more than I want it to return. To wit: bar might equal "a' or 1=1" and lo, every node will be returned. Application error at best, exposure of sensitive data at worst.
>
> Then I thought, well, hey, I have XPath, right? But in XPath, I can construct a query the same way. Hello, security hole.
>
> Am I missing something?
>
>