Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: George Neuner Newsgroups: comp.arch Subject: Re: Byte Addressability And Beyond Date: Wed, 29 May 2024 22:26:00 -0400 Organization: i2pn2 (i2pn.org) Message-ID: References: <1uJ5O.2$gn%7.1@fx12.iad> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Injection-Info: i2pn2.org; logging-data="2625875"; 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: 1981 Lines: 23 On Wed, 29 May 2024 18:42:32 -0000 (UTC), John Levine wrote: >According to EricP : >>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.