Yeah I prefer a whitelist of locked down query request handlers via a proxy that are reasonably well protected. I would never expose update to the web or allow any updating over a public interface.
If you want an example, you can checkout http://solr.quepid.com/solr/statedecoded/select?q=*:*&qt=update&stream.body= <delete><query>*:*</query></delete>&commit=true http://solr.quepid.com/solr/statedecoded/update?stream.body= <delete><query>*:*</query></delete>&commit=true But still get search results back: http://solr.quepid.com/solr/statedecoded/select?q=*:* Click all those all day long. And do let me know if you find holes... I'm sure there's room for improvement Cheers, -Doug On Friday, December 25, 2015, GW <thegeofo...@gmail.com> wrote: > If you are using Linux a simple one liner in IP tables > > iptables -I INPUT \! --src www.yourwebserver.com -m tcp -p tcp --dport > 8983 -j DROP > > > If windows, you can do something similar > > otherwise it is very easy for anyone to delete all your documents with > > http://yoursolrserver.com:8983/solr/your-core/update?stream.body= > <delete><query>*:*</query></delete>&commit=true > > > > > On 25 December 2015 at 20:42, Doug Turnbull < > dturnb...@opensourceconnections.com <javascript:;>> wrote: > > > Hi Shawn > > > > Maybe I should have qualified the parameters of scenarios this make me > > comfortable just proxying Solr directly w/o an API > > > > These situations include: > > > > 1. I've got no qualms about giving the whole world access to every > document > > in the index. There's nothing protected about anything. > > 2. The content can be easily rebuilt , it's not very large. (I can easily > > push a button and make a new one) > > > > Sure you can denial of service Solr, and I might lose my search index. > But > > you can denial of service anything. This includes just about anything you > > put in front of Solr. Moreover, the added complexity of a > > Drupal/Wordpress/your API might only add to the security problems with > > their own security issues. I'd rather keep it simple and have fewer > moving > > parts. > > > > Cases where I would want an API in front of Solr (these are just the > > security ones): > > - I want to protect the content (ie based on some notion of a "user" or > > other permissions) > > - Rebuilding the content would be very hard and time consuming > > > > I would also say to expose Solr directly to everyone you probably should > > know about Solr's bugaboos: > > - the lovely qt parameter and the request dispatcher (the nginx proxy > below > > disallows qt) > > - deep paging (prevented by the nginx proxy) > > - how to lock down a request handler fairly robustly, how to use > invariants > > - mitigating intentionally malicious queries (such as the lovely "sleep" > > function query). > > > > I'm also curious to hear what the websolr people do, or anyone else that > > hosts Solr for the JavaScript app development crowd. > > > > Cheers > > -Doug > > > > > > On Friday, December 25, 2015, Shawn Heisey <apa...@elyograg.org > <javascript:;>> wrote: > > > > > On 12/25/2015 12:17 PM, Eric Dain wrote: > > > > Does allowing javascript direct access to SolrCloud raise security > > > concern? > > > > should I build a REST service in between? > > > > > > > > I need to provide async search capability to web pages. the pages > will > > be > > > > public with no authentication. > > > > > > End users should never have access to Solr. Access to Solr from the > > > end-user machine is required if you want to accept Solr responses > > directly. > > > > > > In one of the other replies that you received, Doug has given you an > > > nginx config for proxying access to Solr -- indirect access. This can > > > protect against *changes* to the index, and it has protection against > > > high start/rows values, but there are many other ways that an attacker > > > can construct denial of service queries, which this proxy config will > > > not prevent. > > > > > > I think that indirect access (through a proxy) should not be allowed > > > either, unless you can trust all the people that will have access. > > > > > > If Solr is open to a sufficiently wide audience (especially the > > > Internet), someone will find a way to abuse the service even with a > > > proxy, either to cause harm or to learn things they shouldn't know. > > > > > > The most secure option is to only allow the webservers and trusted > > > administrators to access Solr. All end user (Internet) access to Solr > > > should be handled through a custom web application. This might be > > > something that you find and install (such as wordpress, drupal, etc), > or > > > one that you write yourself. > > > > > > You can still do AJAX while maintaining security. You'll need to write > > > something in a server-side web programming language like PHP, Java, > etc. > > > This code will need to accept the AJAX requests from your client-side > > > javascript code, validate the request parameters to make sure they're > > > sane, get a response from Solr, and return relevant data. If the > > > parameters don't validate, return an error, and handle that error > > > appropriately in the javascript code. > > > > > > Thanks, > > > Shawn > > > > > > > > > > -- > > *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections > > <http://opensourceconnections.com>, LLC | 240.476.9983 > > Author: Relevant Search <http://manning.com/turnbull> > > This e-mail and all contents, including attachments, is considered to be > > Company Confidential unless explicitly stated otherwise, regardless > > of whether attachments are marked as such. > > > -- *Doug Turnbull **| *Search Relevance Consultant | OpenSource Connections <http://opensourceconnections.com>, LLC | 240.476.9983 Author: Relevant Search <http://manning.com/turnbull> This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.
