Neo4j显式索引Lucene查询谓词如何防范注入？

Great question—this is a common pitfall when working with explicit Lucene indexes in Neo4j, since Cypher's named parameters don't work directly inside the Lucene query string. Here are the most reliable ways to mitigate injection risks:

1. Use APOC's apoc.text.luceneQuery for Safe Parameterization #

APOC provides a handy function that automatically escapes Lucene special characters (like +, -, &&, ", *, etc.) from user input, so you can safely build your query string without manual escaping.

Here's how to adapt your example:

MATCH (d:Decision)-[:HAS_VALUE_ON]->(ch:Characteristic) 
WHERE ch.id = 2 
WITH ch, 
  apoc.text.luceneQuery('property.1.4', $numericValue) + " AND " + 
  apoc.text.luceneQuery('property.1.3', $stringValue) AS safeLuceneQuery
CALL apoc.index.in(ch, 'HAS_VALUE_ON', safeLuceneQuery) YIELD node AS decision 
MATCH (decision)-[ru:CREATED_BY]->(u:User) 
RETURN decision, u

• $numericValue and $stringValue are standard Cypher named parameters populated from your UI input.
• apoc.text.luceneQuery handles all escaping for you—so even if a user inputs something malicious like "practical" OR 1=1, it gets escaped into a harmless literal string.

2. Manually Escape Lucene Special Characters #

If you can't use APOC (though I'd recommend it), you can manually escape all Lucene-reserved characters in user input before building the query string. The characters you need to escape are:
+ - && || ! ( ) { } [ ] ^ " ~ * ? : \ /

For example, in your application code (not Cypher), you'd add a backslash before each of these characters. For instance:

• User input: practical! → Escaped: practical\!
• User input: 5* → Escaped: 5\*

Once escaped, you can safely concatenate the values into your Lucene query string. Note that this approach is error-prone if you miss any special characters, so use it only as a last resort.

3. Migrate to Neo4j Schema Indexes (Best Practice) #

If at all possible, ditch explicit Lucene indexes and use Neo4j's native Schema indexes instead. This lets you use standard Cypher WHERE clauses with named parameters, eliminating injection risks entirely while also improving performance and maintainability.

Your query would look like this (after creating the necessary indexes):

// First create the schema indexes (run once)
CREATE INDEX FOR (d:Decision) ON (d.property.1.4);
CREATE INDEX FOR (d:Decision) ON (d.property.1.3);

// Query with safe named parameters
MATCH (decision:Decision)-[:HAS_VALUE_ON]->(ch:Characteristic)
WHERE ch.id = 2 
  AND decision.property.1.4 = $numericValue
  AND decision.property.1.3 = $stringValue
MATCH (decision)-[ru:CREATED_BY]->(u:User)
RETURN decision, u

Schema indexes are Neo4j's preferred indexing method—they're integrated with the query planner, automatically maintained, and avoid the need to handle raw Lucene syntax.

Key Takeaway #

Never directly concatenate untrusted user input into a Lucene query string. Use either APOC's safe query builder, manual escaping, or (preferably) switch to Schema indexes to eliminate the risk entirely.

内容的提问来源于stack exchange，提问作者alexanoid