Geoff Caplan wrote:
> Are the standard escaping functions found in the PHP, Tcl etc APIs to
> Postgres bombproof? Are there any encodings that might slip through
> and be cast to malicious strings inside Postgres? What about functions
> like convert(): could they be used to slip something through the
> escaping function?
What about writing nessus plugin(s) or a specific scanner for these
escaping issues ? I don't know if a such thing already exists...
--
Olivier