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 നോബിള് नोब्ळ् <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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
