Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 09 Dec 2011 10:49:40 -0600 Message-ID: <4EE23C02.6070302@SPAM.comp-arch.net> Date: Fri, 09 Dec 2011 08:49:06 -0800 From: "Andy \"Krazy\" Glew" Reply-To: andy@SPAM.comp-arch.net Organization: comp-arch.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 Newsgroups: comp.arch,comp.lang,comp.lang.perl,comp.databases,comp.security Subject: Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy References: <4EE0D72E.3010308@SPAM.comp-arch.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Lines: 120 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-wCgc1OXlxAgVYAj+D2U3OfK7RU9+icLkrpdP2vwPFKw1smwXfyPKAgmXe0gWcHUFqysTvZgE/yixAi4!NOjTSh90XHajCq3+StOYPOHthlHMUSzmyfvMEwqD4entk3vTMeIyk85u01s2CgQ= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5266 Xref: x330-a1.tempe.blueboxinc.net comp.arch:5017 comp.databases:149 >> >> The general solution to this is "quotification": take the user input, > > And here is where you go wrong: > > The general solution is to totally separate parsing from user input, > i.e. in your example above you would first parse the SELECT statement, > using question marks as placeholders for where you expect input. > > Later on you execute that prepared (i.e. parsed) statement, substituting > the actual user input for the placeholders: > > I.e. in perl this looks like this: > > # Let the DB parser see only static strings like this: > my $sth = > $dbh->prepare("SELECT FIELDLIST FROM TABLE WHERE NAME = '?'"); > > # Get the possibly poisonous user input > my $user_input = param('name'); > $sth->execute($user_input); Sure. But let me point out a) SQL parameterization is just a form of quotification. It is a form of quotification that has very complicated quote marks, with a level of indirection. b) SQL parameterization is only available in SQL. The example you give, Terje, is not Perl - it is Perl being used to prepare an SQL statement. How does this help me if I am using some other language, that does not have that facility? SQL injection is not the only form of bad quotification attack. Yesterday I was writing some scripts - Perl driving Expect driving csh driving ... heck, I don't know half of what it was driving, since hardware CAD systems are scripts wrapped around scripts wrapped around... I did something as simple as, in Perl system("grep $pattern $filename | $user_provided_filter_command") Many opportunities for shell script injection here. Yes, I am not even sure how the tainting approach would work here. I think that $user_provided_shell_command might be restricted to standard commands available on the target system, default path, not able to invoke arbitrary user code. And constrained not to have shell syntax like < or > or ... inside it. (Might want to have capabilities attachached to string inlining.) Yes, perhaps I should be using exec and not system around strings. I suppose that exec, which is not subject to shell parsing, is the UNIX/shell equivalent And, yes, supposedly what I am writing is internal only, never supposed to be exposed to anyone untrusted. But these are the attitudes that get us in trouble. When it is more work to be secure than it is to be insecure. When we are willing to write insecure code because it is easier, and because we fool ourselves into thinking we will never be exposed. Sure, use SQL paramters. But more and more I reject any "solution" that says a) Every programmer should use feature F in language L. b) Ever programmer should be careful. I look for techniques that apply cross languages, and cross programmers of varying levels of skill. === By the way: a few years ago one of my favorite wikis, Twiki, was compromised because it had a search facility that basically did system("find wiki -type f | grep $user_provided_regexp") The fix? Seems to be rewriting grep in Perl. I object to security fixes that get in the way of code reuse. Another possible fix, the moral equivalent of SQL ? parameterization: $file->write($user_provided_regexp); system("find wiki -type f" . "| grep -regexp_file $file->{name}"); Basically, to provide the moral equivalent of SQL ?, you need to provide -file arguments to all scripts that you want to interpolate user data into. Lots of code to change. I am using a tool a friend of mine wrote that *couold* have such a -file argument, but which he says "just do `cat config-file`" As in foobar `cat config-file-containg-command-line-args` How do you make that safe? Oh, yeah, use Perl, do it youyrself. Q: what would a "securely composable shell scripting language" look like?