You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by "Martin Frank Hansen (MHQ)" <MH...@kmd.dk> on 2020/02/11 09:55:14 UTC

solr-injection

Hi,

I was wondering how others are handling solr – injection in their solutions?

After reading this post: https://www.waratek.com/apache-solr-injection-vulnerability-customer-alert/ I can see how important it is to update to Solr-8.2 or higher.

Has anyone been successful in injecting unintended queries to Solr? I have tried to delete the database from the front-end, using basic search strings and Solr commands, but has yet not been successful (which is good). I think there are many who knows much more about this than me, so would be nice to hear from someone with more experience.

Which considerations do I need to look at in order to secure my Solr core? Currently we have a security layer on top on Solr, but at the same time we do not want to restrict the flexibility of the searches too much.

Best regards

Martin


Internal - KMD A/S

Beskyttelse af dine personlige oplysninger er vigtig for os. Her finder du KMD’s Privatlivspolitik<http://www.kmd.dk/Privatlivspolitik>, der fortæller, hvordan vi behandler oplysninger om dig.

Protection of your personal data is important to us. Here you can read KMD’s Privacy Policy<http://www.kmd.net/Privacy-Policy> outlining how we process your personal data.

Vi gør opmærksom på, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svarfunktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den. Selvom e-mailen og ethvert vedhæftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan påvirke computeren eller it-systemet, hvori den modtages og læses, åbnes den på modtagerens eget ansvar. Vi påtager os ikke noget ansvar for tab og skade, som er opstået i forbindelse med at modtage og bruge e-mailen.

Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or it-system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.

Re: solr-injection

Posted by Jörn Franke <jo...@gmail.com>.
Do not have users accessing Solr directly.

 Have your own secure web frontend/ own APIs for it. In this way you can control secure access.

Secure Solr with https and Kerberos. Have for your web frontend only access rights needed and for your admins only the access rights they need. Automate deployment of configurations through the APIs. Secure Zookeeper (if in cloud mode) with ssl and authentication (eh Kerberos).

Make sure that connection to those two are only allowed for the web frontend and admins ( for the latter have a dedicated jumphost from which connections are allowed). 



> Am 11.02.2020 um 10:55 schrieb Martin Frank Hansen (MHQ) <MH...@kmd.dk>:
> 
> Hi,
> 
> I was wondering how others are handling solr – injection in their solutions?
> 
> After reading this post: https://www.waratek.com/apache-solr-injection-vulnerability-customer-alert/ I can see how important it is to update to Solr-8.2 or higher.
> 
> Has anyone been successful in injecting unintended queries to Solr? I have tried to delete the database from the front-end, using basic search strings and Solr commands, but has yet not been successful (which is good). I think there are many who knows much more about this than me, so would be nice to hear from someone with more experience.
> 
> Which considerations do I need to look at in order to secure my Solr core? Currently we have a security layer on top on Solr, but at the same time we do not want to restrict the flexibility of the searches too much.
> 
> Best regards
> 
> Martin
> 
> 
> Internal - KMD A/S
> 
> Beskyttelse af dine personlige oplysninger er vigtig for os. Her finder du KMD’s Privatlivspolitik<http://www.kmd.dk/Privatlivspolitik>, der fortæller, hvordan vi behandler oplysninger om dig.
> 
> Protection of your personal data is important to us. Here you can read KMD’s Privacy Policy<http://www.kmd.net/Privacy-Policy> outlining how we process your personal data.
> 
> Vi gør opmærksom på, at denne e-mail kan indeholde fortrolig information. Hvis du ved en fejltagelse modtager e-mailen, beder vi dig venligst informere afsender om fejlen ved at bruge svarfunktionen. Samtidig beder vi dig slette e-mailen i dit system uden at videresende eller kopiere den. Selvom e-mailen og ethvert vedhæftet bilag efter vores overbevisning er fri for virus og andre fejl, som kan påvirke computeren eller it-systemet, hvori den modtages og læses, åbnes den på modtagerens eget ansvar. Vi påtager os ikke noget ansvar for tab og skade, som er opstået i forbindelse med at modtage og bruge e-mailen.
> 
> Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachments are free from viruses and other errors that might affect the computer or it-system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.