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

Groups > comp.databases > #149

Re: A_Modest_1_bit_Proposal_about_Quotification_-_making_the_Default_Easy

Cross-posted to 5 groups.

Show all headers | View raw

>>
>> 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?

Back to comp.databases | Previous | Next — Previous in thread | Next 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