Re: Byte Addressability And Beyond

On Sat, 01 Jun 2024 12:49:46 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

George Neuner wrote:

On Wed, 29 May 2024 18:42:32 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:
 

According to EricP  <ThatWouldBeTelling@thevillage.com>:

Ok, you accept international character data, you just don't have to
check >127 characters for "drop table" etc commands.
>
I don't think you are being paranoid enough.
I still think you have to validate or sanitize the >127 string to
ensure the code sequences only contain well formed characters.

If you're sending the strings to a database, the database will
invariably do detailed string validation so I wouldn't bother, but be
prepared for the error code if it rejects the string,

 
Far too much SQL is constructed by simply splicing user input into a
query "template" string.
 
When queries are done right with all user input provided via SQL
parameters, then there is far less need to "sanitize" input.
 
There is a one major caveat: in SQL, table names can't be specified by
parameter.  If the user must provide a table name, then you DO have to
splice the query string and you DO have to be careful.

>
Yes, I didn't mean not parameterizing the string args.
>
I was trying to think of ways that I might get your software to combine
malformed strings creating something different. This would occur after
the strings have been passed using parameterization, like if an index
is built from two concatenated string fields.

Sorry ... was away for a few days.


Even using parameters you still can have a "bad" outcome (for some
definition).  E.g., if the database contains "John" but the query
string is "Jon", it might fail to find or delete existing tuples,
update wrong tuples, create superfluous tuples, etc. ... which can
affect the integrity[*] of the stored data.  However, parameters
provide no way to /rewrite/ the SQL to perform a different operation
than that which was originally intended.

[*] "ACID" provides some guarantees of "consistency" but does not make
any guarantees of "integrity".  The 'I' stands for "isolation".


However, many SQL RDBMS now support operations on JSON and XML data,
and it is possible to affect searches within these types of fields by
using only (SQL) parameter strings.  I don't know of any way to defend
against this without checking code having some fairly sophisticated
understanding of the stored data ... not just its structure, but also
what it represents.