Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Sylvia Else Newsgroups: comp.misc Subject: Re: nosql systems fall for some of the same old traps Date: Mon, 16 Nov 2015 18:52:10 +1100 Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net EALpbjAgXRTMEjkdxmoDwQmFFhUxiapRIT+AezKSXnqR2O59OY Cancel-Lock: sha1:PEQDd5LH+qk4rNQwr09BtDTSw9I= User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: Xref: csiph.com comp.misc:9533 On 13/11/2015 11:36 PM, Rich wrote: > RS Wood wrote: >> http://www.theregister.co.uk/2015/11/13/nosql_security_new_generation/ > >> NoSQL: Injection vaccination for a new generation >> This future architecture still falls into some of the same old traps > >> //--clip >> ... >> NoSQL is, or was meant to be (you pick) the future architecture, an >> opportunity, almost, to start afresh. Given that and with the wealth of >> knowledge that's amassed from decades of SQL, you'd think NoSQL >> databases and systems wouldn?t fall into the same traps as the previous >> generations of RDBM systems. >> //--clip > > Obviously written by a reporter, not by a programmer. > > SQL injection attacks are the result of failing to treat data from > "outside" as possibly malicious until it is defanged. > > The failure has nothing to do with SQL, or even with the connected > database. It is the code that interfaces between the DB and the world. > > That interface code exists, no matter the backing database. And as > long as some programmer writes that code assuming that all input data > is only ponys and unicorns, these issues will continue to occur. > The underlying problem is an insufficient division between the definition of the query to be performed, and the data values to be used. Indeed, in some implementations, the only way to specify the data values is to encode them into the query which is constructed anew for each use. This makes injection attacks inevitable when the work is done by naive developers. Even where the option exists to use parameter references, developers may use the query encoding approach just because it seems easier. The solution is to prevent the appearance of literal values at all in the query language. This can be a pain, of course, where a value is genuinely constant (since it must still be supplied as a parameter), but it does make the system safer in the hands of inexperienced and/or indifferent developers. Sylvia.