Bill Moran <[EMAIL PROTECTED]> wrote:
>
[snip]
>
> Simply put:
> 1) If the untrusted value is a string, using a proper escape sequence should
> make it safe.
> 2) If the untrusted value is not a string, then it should be tested for
> proper value (i.e. if it should be a number, it should be ensured that
> it _is_ a number, and nothing else) invalid values should trigger an
> error.
>
> I don't see how storing the SQL in some different location is the correct
> way to fix anything?
[snip]
>
I agree with Bill. Years ago (more years than I care to recall) I read
a book on structured systems design (IIRC) that advised one should
condition/convert data as early as possible in the process, throughout
the design. Amongst the advantages cited for this tactic was that then
you would know, everywhere else in the system, that you were dealing
only with conditioned data. That practice, taken to heart relatively
early in my career, has always stood me in good stead. Thus I
recommend to others the same approach.
In short: Any data coming from an untrusted source should always be
de-fanged as early as possible.
Jim
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
