On 2010-05-30, Martin Gainty wrote:
> i have mixed feelings about parameterised statements.
>
> On the one hand a parameterised statement would be more
> difficult for a Wireshark criminal to insert their own c**p
> into a database because they would have to know the schema
> a-priori for example they would have to know the names of the
> database, table and the datatypes of these 2 statements
> Insert DateField1 INTO DateTable VALUES(1) would gack as 1 is
> not a valid date
> Insert NumericField1 INTO NumericTable VALUES('A') would gack
> as well as A is not a valid number
>
> But thats only one line of defence..Struts..JSF and other
> Frameworks have field validators so a good design would
> involve 2 tiered defence
> 1)The web folks would put some kind of JS function to
> disallow client know from enetering a invalid date
Sorry, but that isn't a security measure at all, you cannot even ensure
that it is executed. And if it is executed, it is executed on the client
side. It is at best useful for some usability niceties. It catches some
malformed input from non-malicious users, but any criminal just ignores
your JS and builds the request he wants.
> 2)The back-end folks (me) would validate Database params in
> the servlet or the DTO as it makes its way to the VO and
> before any of the offending values get into the database
>
That is what PreparedStatement.set*(...) (and the non-java pendants)
does by properly escaping input and transforming it to a representation
which exactly represents the datatype and not any kind of executable
statement.
> The net effect is wireshark criminals are succeeding in
> making everyone's lives a living hell..the least we can do is
> take their pitchfork away!
>
That is not a problem with (prepared) statements at all, that is a
matter of protecting the wire. If you don't want your transmitted data
to be manipulated, you should use at least encryption or validated
signatures.
--
Robert...
