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 > <lee.a.carr...@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 >
