lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GW <thegeofo...@gmail.com>
Subject Re: AJAX access to Solr Server
Date Sat, 26 Dec 2015 14:33:17 GMT
Yes, your proxy seems to work.

The only thing that bothers me is anyone can query your Solr installation.

The world is not a nice place and I can't tell you how many DOS attacks
I've fended off in the last 30 years.

If I thought you were an a-hole I could set up a few machines and query
your server to a standstill.

About ten years ago I was working on a contract. The competitor that lost
the bid did a email DOS attack on me after they took out a whole bunch car
adds (hot deals) in the local paper.  My email was f###'d and my phone was
ringing off the hook.

Cheers,

GW


On 25 December 2015 at 21:55, Doug Turnbull <
dturnbull@opensourceconnections.com> wrote:

> 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 <thegeoforce@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 <
> > dturnbull@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 <apache@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message