Code injection vulnerability

That article found an application where the query was created by string appending...which is NOT recommended, as it allows this vulnerability. This is why we emphasize using parameters for security (note that in that article the number is NOT handled as a Cypher parameter, thus it is vulnerable).

If the query was handled so inputs were provided as parameters, and not string-appended into the query, then there would be no vulnerability to exploit, as submitted parameter values cannot be interpreted as part of the Cypher query itself, just as a value.

I have a knowledge base article pending release that addresses all of this, I'll post it when it's available.

If you're properly parameterizing your inputs, then the only injection vulnerabilities you would need to worry about are for queries that are using string appending into a query string to be executed dynamically via certain APOC Procedures...and even then, there are ways to design even these queries to use parameters in most contexts.

The tl;dr version:

String appending to a query is always vulnerable, regardless of query language, DON'T EVER DO THIS.

Usage of parameters prevents Cypher injection in nearly all cases, except where dynamic Cypher is string-appended and executed in the query via certain APOC procedures.

1 Like