Closed xristy closed 6 years ago
MarcAgate
commented
6 years ago The only thing I can tell so far is that removing the FILTER make the exception disappear... On the other hand, removing the double quotes in L_name doesn't change a thing. Finally, if I add a FILTER to a similar query (Work_bibl_info), the query keeps working fine !
xristy
commented
6 years ago There's nothing wrong with the query which works fine when a bind is used to supply a value for ?L_name. Seems like the injection test is simply broken. It seems to me that as long as the params are restricted to ints, strings and uris, then there is no opportunity for injection attacks. That should only happen with sparql fragments. Validating that ints are ints, uris are uris, and strings are strings,should be quite sufficient.
eroux
commented
6 years ago Well, while I agree with ints and uris, strings are a more difficult business because of quote escaping, that's the whole thing about injection...
xristy
commented
6 years ago So check for proper quote escaping. The lds-pdi is constructing the strings for the case of lucene string params and so is apparently already doing some escaping.
eroux
commented
6 years ago Well, that's what the injection detector is supposed to do, so I would do something else: reproduce the injection exception bug in a small code and report the bug to Jena...
MarcAgate
commented
6 years ago lds-pdi is not doing any escaping at all : it's passing parameters "as is" to the injectionTracker wich is in fact a wrapper of ParameterizedSparqlString jena Class. This class is in charge of "injecting" param values into the queryCommand, according to sparql syntax and injection tracking policies. Anyway, the issue is that this class is not behaving the same way in similars situations. We might decide to post a question to users@jena about this one, since it might be a bug. Isn't that weird to "solve the issue" by removing the FILTER (which does not involve any param, BTW) ? And even more wierd to not have any issue when addind a filter to a similar query?
xristy
commented
6 years ago The docs on the ParameterizedSparqlString are not clear on whether it checks for escaping in strings much less performs any escaping. It states it doesn't check sparql syntax.
The example query for Work_comment_fast uses "rgyud bla ma" vs the argument rgyud bla ma used in Work_comment. The same argument is used in Work_bibl_info_fast where the quotes must be escaped for the query to work properly. Somewhere the escaping is happening.
Working out a self-contained small test case to report as a bug, or perhaps to users@jena, is appropriate.
MarcAgate
commented
6 years ago Let's take Work_byName. The query passed to the tracker is:
select ?Work_ID ?Work_Name
where {
(?Work_ID ?sc ?Work_Name) text:query ?L_name .
?Work_ID a :Work.
}and the parameter is "chos dbyings" (with double quotes)
After being processed by the tracker, we have:
SELECT ?Work_ID ?Work_Name
WHERE
{ ( ?Work_ID ?sc ?Work_Name )
text:query "\"chos dbyings\"" .
?Work_ID rdf:type :Work
}
LIMIT 500so the proper escaping is done by ParameterizedSparqlString.
xristy
commented
6 years ago Perhaps the docs need some updating
MarcAgate
commented
6 years ago This was a Jena Bug. It's been fixed in the latest release.
The
lds-queries/Work_comment_fastquery is throwing a bogus injection attack complaint. The pattern in the problem query is the same as that oflds-queries/Work_bibl_info_fastandlds-queries/Work_byName: