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 Chris Hostetter <ho...@fucit.org> on 2008/06/27 00:54:33 UTC
Solr Security and XSRF
Solr isn't normally concerned with "Security" related issues...
http://wiki.apache.org/solr/SolrSecurity
"It is strongly recommended that the application server containing Solr
be firewalled such the only clients with access to Solr are your own.
A default/example installation of Solr allows any client with access
to it to add, update, and delete documents"
However: Recent conversations about Cross-Site Scripting (XSS) have made
me realize that even if a Solr instance is protected by good firewalls so
that "bad guys" have no direct access, that instance may be at risk to
potential "Cross-Site Request Forgery" (CSRF) based attacks if the
following are all true:
1) Some number of "good guys" have direct access to that Solr
instance from their web browsers.
2) A "bad guy" knows/guesses the host:port/path of the Solr
instance (even though they can not access it directly).
3) The bad guy can trick one of the good guy into clicking a
maliciously crafted URL, or loading a webpage that contains
malicious javascript.
This is because Solr's most basic behavior is to receive updates and
deletes via HTTP. If you have a firewall or other security measure
restricting Solr's /update handler so it only accepts connections from
approved hosts/clients, but *you* are approved then you could
inadvertently be tricked into loading a web page that initiates an HTTP
Connection to Solr on your behalf.
It's important to keep this in mind when thinking about what it means to
"secure" an instance of Solr (if you have not already).
A basic technique that can be used to mitigate the risk of a possible CSRF
attack like this is to configure your Servlet Container so that access to
paths which can modify the index (ie: /update, /update/csv, etc...) are
restricted either to specific client IPs, or using HTTP Authentication.
Users with tips/suggestions for securing Solr using various Servlet
Container features are encouraged to add those tips to the corresponding
wiki pages...
http://wiki.apache.org/solr/SolrTomcat
http://wiki.apache.org/solr/SolrJetty
http://wiki.apache.org/solr/SolrResin
http://wiki.apache.org/solr/SolrJBoss
And of course: if people have general security tips for Solr, please add
them to the wiki as well...
http://wiki.apache.org/solr/SolrSecurity
See Also: http://en.wikipedia.org/wiki/Cross-site_request_forgery
-Hoss
Re: Solr Security and XSRF
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
SOLR-607 is still open.Till it is committed this solution may not be poossible
--Noble
On Mon, Jun 30, 2008 at 10:23 AM, Noble Paul നോബിള് नोब्ळ्
<no...@gmail.com> wrote:
> If you have a master slave configuration I guess it is a good idea to
> remove the updatehandler altogether from slaves.
> --Noble
>
> On Sat, Jun 28, 2008 at 2:39 AM, Chris Hostetter
> <ho...@fucit.org> wrote:
>>
>> : > A basic technique that can be used to mitigate the risk of a possible CSRF
>> : > attack like this is to configure your Servlet Container so that access to
>> : > paths which can modify the index (ie: /update, /update/csv, etc...) are
>> : > restricted either to specific client IPs, or using HTTP Authentication.
>> :
>> : My understanding is that HTTP authentication is useless against XSRF,
>> : because browsers cache the authentication tokens. Once you have
>> : authenticated, you are still vulnerable to attacks.
>>
>> while I agree that is generally true, my suggestion about using HTTP
>> Authentication was to reduce the number of "clients" that have access to
>> update URLs. if you add authentication but then give everyone on your
>> intranet a username/password it would certianly defeat the point ...
>> people, using web browsers, don't typically need to hit URLs
>> like "/update". Updates are typically sent by other applications, so if
>> you use authentication and hardcode credentials into your "update clients"
>> (which are automated and no going to hit arbitrary URLs maliciously fed to
>> them by bad guys) but do not give credentials to people who surf the
>> public internet you can help mitigate the risk.
>>
>> (of course: if you have a something like a webcrawler scraping webpages
>> and posting the docs directly to Solr, then that crawler could fall prey
>> to a CSRF attack as well -- you'd want to make sure that the
>> "crawl" requests didn't have access to the same credentials needed for
>> sending updates)
>>
>> : Restricting access to the servlet container by IP is probably safer.
>> : To access the admin pages, I proxy the servlet container via Apache,
>> : similar to this snippet given below.
>> :
>> : This requires the user to authenticate via SSL for all SOLR-related
>> : pages, and additionally blocks all update queries. If one also would
>>
>> But doesn't that mean that any system with a legitimate need to update
>> the index has to bypass your proxy? What prevents a CSRF based attack
>> from bypasing your proxy as well?
>> : Comments, anyone? This configuration is container-agnostic, so if no
>> : serious problems are found with my setup, which Wiki page would be
>> : most appropriate for this snippet?
>>
>> It's container agnostic, but does require the use an an Apache HTTPD proxy
>> ... recipies like this seem like they'd be suitable on the SolrSecurity
>> page (but it still seems like there's a missing piece ... restricting the
>> appserver so it only accepts requests from the proxy, and a way for the
>> proxy to pass requests on to /update if and only if they come from
>> specific IPs, or specific "users", etc...
>>
>>
>> -Hoss
>>
>>
>
>
>
> --
> --Noble Paul
>
--
--Noble Paul
Re: Solr Security and XSRF
Posted by Noble Paul നോബിള് नोब्ळ् <no...@gmail.com>.
If you have a master slave configuration I guess it is a good idea to
remove the updatehandler altogether from slaves.
--Noble
On Sat, Jun 28, 2008 at 2:39 AM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : > A basic technique that can be used to mitigate the risk of a possible CSRF
> : > attack like this is to configure your Servlet Container so that access to
> : > paths which can modify the index (ie: /update, /update/csv, etc...) are
> : > restricted either to specific client IPs, or using HTTP Authentication.
> :
> : My understanding is that HTTP authentication is useless against XSRF,
> : because browsers cache the authentication tokens. Once you have
> : authenticated, you are still vulnerable to attacks.
>
> while I agree that is generally true, my suggestion about using HTTP
> Authentication was to reduce the number of "clients" that have access to
> update URLs. if you add authentication but then give everyone on your
> intranet a username/password it would certianly defeat the point ...
> people, using web browsers, don't typically need to hit URLs
> like "/update". Updates are typically sent by other applications, so if
> you use authentication and hardcode credentials into your "update clients"
> (which are automated and no going to hit arbitrary URLs maliciously fed to
> them by bad guys) but do not give credentials to people who surf the
> public internet you can help mitigate the risk.
>
> (of course: if you have a something like a webcrawler scraping webpages
> and posting the docs directly to Solr, then that crawler could fall prey
> to a CSRF attack as well -- you'd want to make sure that the
> "crawl" requests didn't have access to the same credentials needed for
> sending updates)
>
> : Restricting access to the servlet container by IP is probably safer.
> : To access the admin pages, I proxy the servlet container via Apache,
> : similar to this snippet given below.
> :
> : This requires the user to authenticate via SSL for all SOLR-related
> : pages, and additionally blocks all update queries. If one also would
>
> But doesn't that mean that any system with a legitimate need to update
> the index has to bypass your proxy? What prevents a CSRF based attack
> from bypasing your proxy as well?
> : Comments, anyone? This configuration is container-agnostic, so if no
> : serious problems are found with my setup, which Wiki page would be
> : most appropriate for this snippet?
>
> It's container agnostic, but does require the use an an Apache HTTPD proxy
> ... recipies like this seem like they'd be suitable on the SolrSecurity
> page (but it still seems like there's a missing piece ... restricting the
> appserver so it only accepts requests from the proxy, and a way for the
> proxy to pass requests on to /update if and only if they come from
> specific IPs, or specific "users", etc...
>
>
> -Hoss
>
>
--
--Noble Paul
Re: Solr Security and XSRF
Posted by Chris Hostetter <ho...@fucit.org>.
: > A basic technique that can be used to mitigate the risk of a possible CSRF
: > attack like this is to configure your Servlet Container so that access to
: > paths which can modify the index (ie: /update, /update/csv, etc...) are
: > restricted either to specific client IPs, or using HTTP Authentication.
:
: My understanding is that HTTP authentication is useless against XSRF,
: because browsers cache the authentication tokens. Once you have
: authenticated, you are still vulnerable to attacks.
while I agree that is generally true, my suggestion about using HTTP
Authentication was to reduce the number of "clients" that have access to
update URLs. if you add authentication but then give everyone on your
intranet a username/password it would certianly defeat the point ...
people, using web browsers, don't typically need to hit URLs
like "/update". Updates are typically sent by other applications, so if
you use authentication and hardcode credentials into your "update clients"
(which are automated and no going to hit arbitrary URLs maliciously fed to
them by bad guys) but do not give credentials to people who surf the
public internet you can help mitigate the risk.
(of course: if you have a something like a webcrawler scraping webpages
and posting the docs directly to Solr, then that crawler could fall prey
to a CSRF attack as well -- you'd want to make sure that the
"crawl" requests didn't have access to the same credentials needed for
sending updates)
: Restricting access to the servlet container by IP is probably safer.
: To access the admin pages, I proxy the servlet container via Apache,
: similar to this snippet given below.
:
: This requires the user to authenticate via SSL for all SOLR-related
: pages, and additionally blocks all update queries. If one also would
But doesn't that mean that any system with a legitimate need to update
the index has to bypass your proxy? What prevents a CSRF based attack
from bypasing your proxy as well?
: Comments, anyone? This configuration is container-agnostic, so if no
: serious problems are found with my setup, which Wiki page would be
: most appropriate for this snippet?
It's container agnostic, but does require the use an an Apache HTTPD proxy
... recipies like this seem like they'd be suitable on the SolrSecurity
page (but it still seems like there's a missing piece ... restricting the
appserver so it only accepts requests from the proxy, and a way for the
proxy to pass requests on to /update if and only if they come from
specific IPs, or specific "users", etc...
-Hoss
Re: Solr Security and XSRF
Posted by Christian Vogler <ch...@gmail.com>.
On Fri, Jun 27, 2008 at 1:54 AM, Chris Hostetter
<ho...@fucit.org> wrote:
> A basic technique that can be used to mitigate the risk of a possible CSRF
> attack like this is to configure your Servlet Container so that access to
> paths which can modify the index (ie: /update, /update/csv, etc...) are
> restricted either to specific client IPs, or using HTTP Authentication.
My understanding is that HTTP authentication is useless against XSRF,
because browsers cache the authentication tokens. Once you have
authenticated, you are still vulnerable to attacks.
Restricting access to the servlet container by IP is probably safer.
To access the admin pages, I proxy the servlet container via Apache,
similar to this snippet given below.
This requires the user to authenticate via SSL for all SOLR-related
pages, and additionally blocks all update queries. If one also would
like to block specific admin pages, one could conceivably do so by
adding <Location> + Deny directives.
Comments, anyone? This configuration is container-agnostic, so if no
serious problems are found with my setup, which Wiki page would be
most appropriate for this snippet?
<VirtualHost *:443>
ServerName your.server.name
ServerAdmin webmaster@localhost
SSLEngine on
SSLCertificateFile /etc/ssl/certs/your_cert.pem
SSLCertificateKeyFile /etc/ssl/private/your_key.pem
DocumentRoot /var/webroot/www/webadmin/html
ErrorLog /var/webroot/www/webadmin/logs/error_ssl.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/webroot/www/webadmin/logs/access_ssl.log combined
# SOLR admin pages
<Proxy *>
Order deny,allow
Allow from all # change this to restrict to specific
IP addresses
</Proxy>
ProxyPreserveHost On
ProxyRequests Off
ProxyPass /solr/admin http://127.0.0.1:9000/solr/admin
ProxyPassReverse /solr/admin http://127.0.0.1:9000/solr/admin
ProxyPass /solr/select http://127.0.0.1:9000/solr/select
ProxyPassReverse /solr/select http://127.0.0.1:9000/solr/select
<Location /solr>
AuthType Basic
AuthName "SOLR Admin Pages"
AuthUserFile /var/webroot/www/webadmin/auth/solr-auth
Require valid-user
</Location>
</VirtualHost>
Best regards
- Christian