Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases > #152

Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy

Cross-posted to 5 groups.

Show all headers | View raw

Andy "Krazy" Glew wrote:
>
>>>
>>> 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.

I disagree:

The key isn't quotification, rather the opposite: By separating out all 
parsing, doing it up front, before ever reading in any user input, you 
don't need any quoting at all:

The SQL will simply fail to find any matching tables if you try to 
inject any funky code.

I.e. allowing execution of user-supplied data is morally equivalent to 
the macro facility in Microsoft Office, something which has been 
responsible for a large fraction of all virus/trojan/day-0 attacks.
>
> 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.

I agree.
>
> 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")

Wow!
>
> 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

Right.
>
> 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.

Very worthwhile goal!

I really don't think changing the character set used for programming has 
a snowball in hell's chance of surviving though. :-)

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Back to comp.databases | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-12-08 07:26 -0800
  Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Robert Wessel <robertwessel2@yahoo.com> - 2011-12-08 13:09 -0600
    Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Quadibloc <jsavard@ecn.ab.ca> - 2011-12-09 10:55 -0800
      Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Robert Wessel <robertwessel2@yahoo.com> - 2011-12-10 00:27 -0600
  Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-12-08 22:40 +0100
    Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Morten Reistad <first@last.name> - 2011-12-09 01:06 +0100
    Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-12-09 08:49 -0800
      Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy timcaffrey@aol.com (Tim McCaffrey) - 2011-12-09 20:19 +0000
      Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-12-09 22:20 +0100

csiph-web