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
