: > 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
