A Parameterized SPARQL String is a SPARQL query/update into which values may be injected.
Values may be injected in several ways:
Any variable in the command may have a value injected to it, injecting a value replaces all usages of that variable in the command i.e. substitutes the variable for a constant, injection is done by textual substitution.
You can use JDBC style positional parameters if you prefer, a JDBC style parameter is a single ? followed by whitespace or certain punctuation characters (currently ; , .). Positional parameters have a unique index which reflects the order in which they appear in the string. Positional parameters use a zero based index.
Additionally you may use this purely as a StringBuffer
replacement for creating queries since it provides a large variety of
convenience methods for appending things either as-is or as nodes (which
causes appropriate formatting to be applied).
The intended usage of this is where using a QuerySolutionMap
as
initial bindings is either inappropriate or not possible e.g.
This class is useful for preparing both queries and updates hence the
generic name as it provides programmatic ways to replace variables in
the query with constants and to add prefix and base declarations. A
Query
or UpdateRequest
can be created using
the asQuery()
and asUpdate()
methods assuming the command an
instance represents is actually valid as a query/update.
Query
or UpdateRequest
.While this class was in part designed to prevent SPARQL injection it is by no means foolproof because it works purely at the textual level. The current version of the code addresses some possible attack vectors that the developers have identified but we do not claim to be sufficiently devious to have thought of and prevented every possible attack vector.
Therefore we strongly recommend that users concerned about SPARQL Injection attacks perform their own validation on provided parameters and test their use of this class themselves prior to its use in any security conscious deployment. We also recommend that users do not use easily guess-able variable names for their parameters as these can allow a chained injection attack though generally speaking the code should prevent these.