lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Douglas McGilvray ...@weemondo.com>
Subject Re: Securing field level access permission by filtering the query itself
Date Fri, 30 Oct 2015 14:51:34 GMT

Scott thanks for the reply. I like the idea of mapping all the fieldnames internally, adding
security through obscurity. My question therefore would be what is the definitive list of
query parameters that one must filter to ensure a particular field is not exposed in the query
response? Am I missing in the following?

fl
facect.field
facet.pivot
json.facet
terms.fl


kr
Douglas


> On 30 Oct 2015, at 07:37, Scott Stults <sstults@opensourceconnections.com> wrote:
> 
> Douglas,
> 
> Managing a per-user-group whitelist of fields outside of Solr seems the
> best approach. When the query comes in you can then filter out any fields
> not contained in the whitelist before you send the request to Solr. The
> easy part will be to do that on URL parameters like fl. Depending on how
> your app generates the actual query string, you may want to also scan that
> for fielded query clauses (eg "badfield:value") and localParams (eg
> "{!dismax qf=badfield}value").
> 
> Secondly, you can map internal Solr fields to aliases using this syntax in
> the fl parameter: "display_name:real_solr_name". So when the request comes
> in from your app, first you'll map from the requested field alias names to
> internal Solr names (while enforcing the whitelist), and then in the fl
> parameter supply the aliases you want sent in the response.
> 
> 
> k/r,
> Scott
> 
> On Wed, Oct 28, 2015 at 6:58 PM, Douglas McGilvray <dm@weemondo.com> wrote:
> 
>> Hi all,
>> 
>> First I’d like to say the nested facets and the json facet api in
>> particular have made my world much better, I thank everyone involved, you
>> are all awesome.
>> 
>> In my implementation has much of the solr query building working on the
>> browser, solr is behind a php server which acts as “proxy” and doorman,
>> filtering at the document level according to user role and supplying some
>> sensible maximums …
>> 
>> However we now wish to filter just one or two potentially sensitive fields
>> in one document type according to user role (as determined in the php
>> proxy). Duplicating documents (or cores) seems like overkill for just two
>> fields in one document type .. I wondered if it would be feasible (in the
>> interests of preventing malicious activity) to filter the query itself
>> whether it be parameters (fl, facet.fields, terms, etc) … or even deny any
>> request in which fieldname occurs …
>> 
>> Is there someway someone might obscure a fieldname in a request?
>> 
>> Kind Regards & thanks in davacne,
>> Douglas
> 
> 
> 
> 
> -- 
> Scott Stults | Founder & Solutions Architect | OpenSource Connections, LLC
> | 434.409.2780
> http://www.opensourceconnections.com


Mime
View raw message