The update handlers are now implicitly defined (3 or 4 of them). So, it actually needs to be explicitly shadowed and overridden with other Noop handler. And block Config API to avoid attackers creating new handlers.
Regards, Alex. On Thu, 8 Oct 2020 at 14:54, David Hastings <dhasti...@wshein.com> wrote: > > Well that’s why I suggested deleting the update handler :) > > > On Oct 8, 2020, at 2:52 PM, Walter Underwood <wun...@wunderwood.org> wrote: > > > > Let me know where it is and I’ll delete all the documents in your > > collection. > > It is easy, just one HTTP request. > > > > https://gist.github.com/nz/673027/313f70681daa985ea13ba33a385753aef951a0f3 > > > > wunder > > Walter Underwood > > wun...@wunderwood.org > > http://observer.wunderwood.org/ (my blog) > > > >> On Oct 8, 2020, at 11:49 AM, Alexandre Rafalovitch <arafa...@gmail.com> > >> wrote: > >> > >> I think there were past discussions about people doing but they really > >> really knew what they were doing from a security perspective, not just > >> Solr one. > >> > >> You are increasing your risk factor a lot, so you need to think > >> through this. What are you protecting and what are you exposing. Are > >> you trying to protect the updates? You may be able to do it with - for > >> example - read-only docker container, or with embedded Solr or/and > >> with reverse proxy. > >> > >> Are you trying to protect some of the data from being read? Even harder. > >> > >> There are implicit handlers, admin handlers, 'qt' to select query > >> parser, etc. Lots of things to think about. > >> > >> It just may not be worth it. > >> > >> Regards, > >> Alex. > >> > >> > >>> On Thu, 8 Oct 2020 at 14:27, Marco Aurélio <aurelio.marco...@gmail.com> > >>> wrote: > >>> > >>> Hi! > >>> > >>> We're looking into the option of setting up search with Solr without an > >>> intermediary application. This would mean our backend would index data > >>> into > >>> Solr and we would have a public Solr endpoint on the internet that would > >>> receive search requests directly. > >>> > >>> Since I couldn't find an existing solution similar to ours, I would like > >>> to > >>> know whether it's possible to secure Solr in a way that allows anyone only > >>> read-access only to collections and how to achieve that. Specifically > >>> because of this part of the documentation > >>> <https://lucene.apache.org/solr/guide/8_5/securing-solr.html>: > >>> > >>> *No Solr API, including the Admin UI, is designed to be exposed to > >>> non-trusted parties. Tune your firewall so that only trusted computers and > >>> people are allowed access. Because of this, the project will not regard > >>> e.g., Admin UI XSS issues as security vulnerabilities. However, we still > >>> ask you to report such issues in JIRA.* > >>> Is there a way we can restrict read-only access to Solr collections so as > >>> to allow users to make search requests directly to it or should we always > >>> keep our Solr instances completely private? > >>> > >>> Thanks in advance! > >>> > >>> Best regards, > >>> Marco Godinho > >
