Re: Prepared Statements

> eewwww.
>
> in a multi-tier architecture where the code that actually talks to
> the database is isolated from the GUI, this is a totally unreasonable
> expectation -- you really need to audit fields in the GUI, not somewhere
> way back in the code.

Which it should be done indeed, but you also can't expect that a
middle-ware can correctly escape an input string against injection
attacks, as it can't know all the JDBC drivers it will talk to... this
is the job of the JDBC driver, the app talking to it should not even
attempt this.

>
> even if PostgreSQL's jdbc driver somehow had wonderful code to handle
> security problems, sensible DB independent code will _still_ need to audit
> in the GUI because there is no reasonable expectation that all jdbc drivers
> that might be used will have similar code.
>
This is not just about security problems fixed, it's about deterministic
behavior. If you have a non standard driver, you will not know how it
behaves unless you try out every possible input, and even less how it
will behave tomorrow. That's why is so important to have standards
compliance.

> i understand your desire for a single point of control, but moving this
> into the jdbc driver is simply wrong. there are simply better ways;
> java/swing/javabeans are powerful tools.
>

Yes, the application has to validate it's data, but this has nothing to
do with the JDBC validation. There could be perfectly valid data from
the application point of view which can result in unexpected results if
the driver doesn't do it's validation job correctly.

Cheers,
Csaba.

> richard
> --
> Richard Welty rwelty(at)averillpark(dot)net
> Averill Park Networking 518-573-7592
> Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>