FYI, I've added a simple PropertyValidator interface:
http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/extensions/search/src/main/java/org/apache/cxf/jaxrs/ext/search/visitor/PropertyValidator.java
So, if updating setters in classes like Book is not ideal (example, Book
may have been generated) then registering a custom validator on any of
the shipped visitor/builder will let check the specific values as well...
Combining with not supporting properties which may hold some unexpected
characters should be enough...
Thanks,
Sergey
On 26/06/13 14:27, Sergey Beryozkin wrote:
Thinking more about it, probably does not make sense to try and
*generalize* the creation of PreparedStatements. PreparedStatement is
quite hardcoded, the only variations there are the actual column values,
and it just does not match what a FIQL expression may offer.
Basically, when one wants to use a visitor like SQLPrinterVisitor one
should follow some steps one should do always anyway when having SQL
expressions prepared in the application code:
- do not accept the properties that are not expected to be searched
against (that is why having a bean with a limited set of properties helps)
- validate the bean properties (at the bean setter level or at the
visitor level - to be supported shortly)
- build a custom SQL expression and/or PreparedStatement manually, there
are examples on the wiki showing how to iterate over the captured FIQL
expression, get the property name/value, etc
Cheers, Sergey
On 26/06/13 13:59, Sergey Beryozkin wrote:
Hi
On 26/06/13 13:31, nikosdim wrote:
Hi
Interesting. Well, that sounds like a general issue, right ? Whenever a
user submits a query of some sort and the application code builds and
SQL query (lets even not talk about a FIQL SQL handler) then there's
always a danger there that a query value may have something bad encoded
there...
Yes you are right on this. However, in order to avoid that type of
vulnerability, there could be a method in the visitor, lets say
getPreparedStatement(), that would return a prepared Statement instead
of an
SQL String. Is this possible? and also is it worth to implement
something
like that?
May be it is possible, we probably would want to create another visitor
for it, which would produce a prepared statement. Need to think about it.
How do you mean ? You have "name=some bad expression", you have the
domain knowledge of what a 'name' is. There must be a way to validate
what 'name' may be, otherwise there would always be an injection issue
hanging around
Yes but if you don't have the domain of a name and you have a field
called
password which allows alphanumeric characters including special
characters
like =/\etc then you cannot validate against it.
Technically it is true, but then I guess one would not search or allow
searching against such properties in the first place ? That is why
having a bean like Book.class ensures one would not accept by accident a
property like might be able to 'host' a bad expression.
Let us see if we can support prepared statements
Cheers, Sergey
Thanks
--
View this message in context:
http://cxf.547215.n5.nabble.com/Is-FIQL-SQL-Injection-safe-tp5729800p5729871.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
