0

I'm new to ES and wondering if the search function sanitizes the inner "query" field in the body parameter when handed something like:

   "query": {
      "filtered": {
         "query": {
            "match": {
               "_all": {
                  "query": "[THIS PARAMETER]",
                  "operator": "and"
               }
            }
         }
       }
     }

I've tried every input I can to break it and I can't seem to. I created a sanitization function but that was actually leading to worse search results when searching strings such as "&" or "+". I've looked through the code and can't seem to find any obvious sanitization of that field. I just want to be sure before I send a user's search query right through the function.

Thanks

James E
  • 1
  • 1
  • That query field is part of the JSON body, why would Python do anything to it? – OneCricketeer Feb 01 '16 at 00:03
  • Here's the source for [`search`](https://github.com/elastic/elasticsearch-py/blob/master/elasticsearch/client/__init__.py#L453-L531) – OneCricketeer Feb 01 '16 at 00:04
  • Because it's a library that's meant to abstract much of the ES functionality. I figured it's possible it could be iterating the dictionary and sanitizing known inputs, the same way an ORM does that to protect against SQL injection. – James E Feb 01 '16 at 00:28
  • Here is an elasticsearch sanitizer gist, based on a different StackOverflow question https://gist.github.com/eranhirs/5c9ef5de8b8731948e6ed14486058842 – Eran H. Dec 24 '16 at 21:58

1 Answers1

0

I see three more possible approaches to validate es against an inverted attack against the indexes, which are databases, in an attack similar to SQL injection:

  1. How well do you know Lucene and how it handles attacks? Pursuing Lucene architecture and supporting code directly may provide you with insight into how es handles attacks

  2. Try a SOLR approach, which also uses Lucene, and see how SOLR handles attacks; SOLR fell behind es, then has been catching up and improving other areas; there are some interesting SWOT architectural comparisons between es and SOLR

  3. Lay down part of the ELK stack--at least Kibana and es, and test Kibana, which may generate other es/Lucene code that you could test

mouviciel
  • 62,742
  • 10
  • 106
  • 135
MethodyM
  • 105
  • 1
  • 7