Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.arch
Subject: Re: Article on new mainframe use
Date: Fri, 16 Aug 2024 13:43:27 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <kmvubjdn7ub4bkgfhpj89c5vsl37vpp16d@4ax.com>
References: <v9iqko$h7vd$1@dont-email.me> <bb873f7f6a14f222f73abacd698e60eb@www.novabbs.org> <3f8sbj9chugcr6arbpck2t7nb0g87ff6ik@4ax.com> <f7fe11f84f9342f0a7e27d4a729aadad@www.novabbs.org> <li71t8Fs9jnU1@mid.individual.net> <v9mc57$15mm9$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Info: i2pn2.org;
	logging-data="2803728"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="h5eMH71iFfocGZucc+SnA0y5I+72/ecoTCcIjMd3Uww";
User-Agent: ForteAgent/8.00.32.1272
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 2889
Lines: 42

On Fri, 16 Aug 2024 02:05:27 -0000 (UTC), Lawrence D'Oliveiro
<ldo@nz.invalid> wrote:


>The best way to interface to [relational] DBMS was to be able to generate SQL 
>strings on the fly; but this required some facility with manipulation of 
>dynamic, variable-length strings, which COBOL completely lacked. And so 
>special extensions were tacked on, just to cope with the generation of SQL 
>queries and templates.

You mean the *WORST* way.

Just about every SQL injection attack is made possible by programmers
dynamically generating queries.  Most[1] attacks can be prevented
simply by proper use of SQL parameters.


There are only a few situations in which dynamic SQL actually is
necessary - it is not possible to specify table or column names using
parameters, so to reuse a query with a different table or column name
does require generating new query text.

Some applications do have a need to do this - but in most cases the
names to use will be known statically, will be predictable (e.g., date
related), or, if necessary, can be discovered by querying the database
schema - so they should not be provided by user input.

The only exception is to permit a user to create a new *custom* table
type ... but there is little/no need for most applications to do this.
Most applications that must create new tables at runtime know what
names to use, and/or how to generate them, and do not need any input
from a user to do so.

If creating custom table types with user specified names even is
permitted by the application, it should be an operation reserved to
privileged users [presumably who know what they are doing].


---
[1] many RDBMS now directly support JSON and/or XML data, and it is
possible via SQL parameters to inject false "path" information for
working with these data types.  To guard against this the application
itself has to be aware of the data layout.