in reply to Untainting safely. (b0iler proofing?)

takes a string and removes all 'unsafe' (meta) characters
That's too broad. What's unsafe to the shell is not unsafe to an email address, and vice versa.

And contrary to what I picked up from skimming that long article, the best way to keep the shell from interpreting unsafe characters is to not even use a shell at all! Most child process invocations can use a shell-less invocation (multiple arguments to system or exec), and then there's never a problem with the potential characters in the first place!

So, while I understand what you are trying to do, I don't understand why you are even trying to do it. You're starting at the wrong end of the picture.

-- Randal L. Schwartz, Perl hacker

  • Comment on •Re: Untainting safely. (b0iler proofing?)

Replies are listed 'Best First'.
Re^2: Untainting safely. (b0iler proofing?)
by tadman (Prior) on Jun 25, 2002 at 23:55 UTC
    I think what BrowserUK might be asking for is a library that can be used to handle the "usual" types of data. I'm interested in such a thing, as time and time again, people are untainting the same kinds of data.

    Admittedly, such a module would never be strictly perfect, but it would be arguably better than the current condition. Positive progress is better than nothing, isn't it?

    What about validators or untainters for such common bits of data as:
    • Dates
    • Times
    • Names
    • Integers
    • Phone Numbers
    • Postal Codes
    • URLs
    • E-mail addresses
    • Free-form comments
    These are, of course, vague concepts at best, but as an example, as wild and wooly as telephone numbers get, they usually don't have ampersands, double-quotes, or backslashes in them. Likewise, e-mail addresses can contain quite a lot of hair, but there are certain characters that are just not valid.

    The idea is not that things are not necessarily valid names, phone numbers or e-mail addresses, but that they are at least, not dangerous or radioactive. In other words, a name of "Smith'; DROP TABLE foo;" would not be valid.

    Just an idea.
[reply]
      URLs and email addresses are never "unsafe" when handled safely. So if you're looking for Email::Valid, it's done.

      And why you would be passing a date, time, or name near a shell. I'm still confused. That's still thinking from the wrong end.

      As for your DROP TABLE example, if you are using placeholders correctly, that value wouldn't matter.

      So, I'm still not convinced that there needs to be a standard "untainting" library. When the data is handled properly, we don't need to "match" "safe" data. Period.

      -- Randal L. Schwartz, Perl hacker

[reply]

        And why you would be passing a date, time, or name near a shell.

        This is a contrived example but: system( "touch file " $date ); where $date contained "01/01/2002|some nasty command" might cause trouble? Are there NO situations where a date provided from external sources might be used? Granted, almost any type of validation would catch this, but what about the "01/01/2002\0|some nasty command" thing? Would passing this to one the build-in date functions that uses the underlying C libs leave the postfixed command in-place?

        That's still thinking from the wrong end.

        What is the right end?

        As for your DROP TABLE example, if you are using placeholders correctly, that value wouldn't matter.

        Placeholders? - In truth I know what they are, but many an SQL novice does not.

        So, I'm still not convinced that there needs to be a standard "untainting" library.

        Respectfully, I disagree. Look here for the list of big name companies, with big budgets that having employed 'experts' to code, test and review their big projects, that have, and still are managing to make (often expensive) mistakes.

        The idea is to use the collective expertise of PM to construct and refine a publicly available, publicly reviewable (that's one of the open source movement's lorded aims isn't it?) safe mechanism for handling external data for use by us mere mortals.

        When the data is handled properly, we don't need to "match" "safe" data.

        There are two problems with that statement (IMO).

        1) What constitutes "handled properly"? How does one become conversant with the appropriate techniques? Do you have to have nn years, written x-hundreds (thousands??) of lines of code and have been bitten mm-times, before you are sure that you know how to handle the data correctly. Is it not possible to provide a short cut to this?

        2) Somewhat repetitious but - EBay, Yahoo, MS, US Army, the Whitehouse have all fallen foul of thinking they were safe. I know not if any of them were using Perl, but the point remains the same. Even experts make mistakes. An open source library could address this I think.

        Period.

        ?

        BrowserUK (mistakenly posted anonymously)

        Added attribution - dvergin 2002-06-28

[reply]
[d/l]
        There are some untainting modules on CPAN:

      • String::ShellQuote "contains some functions which are useful for quoting strings which are going to pass through the shell or a shell-like object."

      • CGI::Untaint "provides a simple, convenient, abstracted and extensible manner for validating and untainting the input from web forms." Including dates, email, urls, isbn, uk postal codes, and credit card numbers!

        --
        Check out my Perlmonks Related Scripts like framechat, reputer, and xNN.

[reply]

In Section Seekers of Perl Wisdom