You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Lee Carroll <le...@googlemail.com> on 2014/11/26 15:56:54 UTC
cross site scripting
Hi All,
In solr 4.7 this query
/solr/coreName/select/?q=*:*&fl=%27nasty%20value%27&rows=1&wt=json
returns
{"responseHeader":{"status":0,"QTime":2},"response":{"numFound":189796,"start":0,"docs":[{"'nasty
value'":"nasty value"}]}}
This is naughty. Has this been seen before / fixed ?
Re: cross site scripting
Posted by Yonik Seeley <yo...@heliosearch.com>.
On Wed, Nov 26, 2014 at 11:41 AM, Lee Carroll
<le...@googlemail.com> wrote:
> Just out of interest, what is the use-case for a pseudo-field whose value
> is a repeat of the field name?
Not having to specify a field name for the function query:
fl=add(x,y)
somes back as (for example)
"add(x,y)" : 14.2
And constants can be function queries too (hence the oddity you see
using fl=<constant_value> w/o an alias)
But since we don't really restrict document field names, or indexed
field values, clients should be prepared to handle anything (i.e.
"bad" values for some clients could still exist even w/o
pseudo-fields).
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
Re: cross site scripting
Posted by Lee Carroll <le...@googlemail.com>.
Ok. So for the purposes of documenting the thread the pseudo-fields stuff
is here
https://issues.apache.org/jira/browse/SOLR-2444
The solution is either allow clients to generate queries which use pseudo
field queries and ensure the client uses returned data with care (as if it
is user input)
or
generate pseudo-fields if needed only on the server and do not allow
clients to generate them.
Just out of interest, what is the use-case for a pseudo-field whose value
is a repeat of the field name?
On 26 November 2014 at 15:55, Yonik Seeley <yo...@heliosearch.com> wrote:
> On Wed, Nov 26, 2014 at 10:47 AM, Lee Carroll
> <le...@googlemail.com> wrote:
> > The applications using the data may write solr data to the dom. (I doubt
> > they do but they could now or in the future. They have an expectation of
> > trusting the data back from solr).
> >
> > As a straight forward attack you are right though. But it is incorrect
> > behavior? It should not produce bogus fields and values for each record
> > returned ?
>
> That's actually by design (pseudo-fields). You can also set arbitrary
> output keys for other stuff like faceting.
> In general, it's not possible to escape dangerous values for the
> client since the number of clients is practically unlimited (i.e. we
> don't know if values will be used in a SQL query, a PHP front-end, or
> whatever). All we can do is ensure that we correctly encapsulate
> values and then leave the rest up to the client who knows how they
> will use the values.
>
> -Yonik
> http://heliosearch.org - native code faceting, facet functions,
> sub-facets, off-heap data
>
Re: cross site scripting
Posted by Yonik Seeley <yo...@heliosearch.com>.
On Wed, Nov 26, 2014 at 10:47 AM, Lee Carroll
<le...@googlemail.com> wrote:
> The applications using the data may write solr data to the dom. (I doubt
> they do but they could now or in the future. They have an expectation of
> trusting the data back from solr).
>
> As a straight forward attack you are right though. But it is incorrect
> behavior? It should not produce bogus fields and values for each record
> returned ?
That's actually by design (pseudo-fields). You can also set arbitrary
output keys for other stuff like faceting.
In general, it's not possible to escape dangerous values for the
client since the number of clients is practically unlimited (i.e. we
don't know if values will be used in a SQL query, a PHP front-end, or
whatever). All we can do is ensure that we correctly encapsulate
values and then leave the rest up to the client who knows how they
will use the values.
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
Re: cross site scripting
Posted by Lee Carroll <le...@googlemail.com>.
The applications using the data may write solr data to the dom. (I doubt
they do but they could now or in the future. They have an expectation of
trusting the data back from solr).
As a straight forward attack you are right though. But it is incorrect
behavior? It should not produce bogus fields and values for each record
returned ?
On 26 November 2014 at 15:34, Yonik Seeley <yo...@heliosearch.com> wrote:
> It would have been helpful if you would have pointed out exactly what
> you think the problem is.
> I still don't see an issue, since it doesn't look like any
> encapsulation has been broken.
>
> -Yonik
> http://heliosearch.org - native code faceting, facet functions,
> sub-facets, off-heap data
>
>
> On Wed, Nov 26, 2014 at 9:56 AM, Lee Carroll
> <le...@googlemail.com> wrote:
> > Hi All,
> > In solr 4.7 this query
> > /solr/coreName/select/?q=*:*&fl=%27nasty%20value%27&rows=1&wt=json
> >
> > returns
> >
> >
> {"responseHeader":{"status":0,"QTime":2},"response":{"numFound":189796,"start":0,"docs":[{"'nasty
> > value'":"nasty value"}]}}
> >
> > This is naughty. Has this been seen before / fixed ?
>
Re: cross site scripting
Posted by Yonik Seeley <yo...@heliosearch.com>.
It would have been helpful if you would have pointed out exactly what
you think the problem is.
I still don't see an issue, since it doesn't look like any
encapsulation has been broken.
-Yonik
http://heliosearch.org - native code faceting, facet functions,
sub-facets, off-heap data
On Wed, Nov 26, 2014 at 9:56 AM, Lee Carroll
<le...@googlemail.com> wrote:
> Hi All,
> In solr 4.7 this query
> /solr/coreName/select/?q=*:*&fl=%27nasty%20value%27&rows=1&wt=json
>
> returns
>
> {"responseHeader":{"status":0,"QTime":2},"response":{"numFound":189796,"start":0,"docs":[{"'nasty
> value'":"nasty value"}]}}
>
> This is naughty. Has this been seen before / fixed ?
Re: cross site scripting
Posted by Alexandre Rafalovitch <ar...@gmail.com>.
I think I saw some JIRAs on various items, but not sure about this specific one.
But are you exposing Solr directly to the web? Because that's a big
no-no for multiple reasons.
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853
On 26 November 2014 at 09:56, Lee Carroll <le...@googlemail.com> wrote:
> Hi All,
> In solr 4.7 this query
> /solr/coreName/select/?q=*:*&fl=%27nasty%20value%27&rows=1&wt=json
>
> returns
>
> {"responseHeader":{"status":0,"QTime":2},"response":{"numFound":189796,"start":0,"docs":[{"'nasty
> value'":"nasty value"}]}}
>
> This is naughty. Has this been seen before / fixed ?