in reply to •Re: Re^2: Untainting safely. (b0iler proofing?)
in thread Untainting safely. (b0iler proofing?)

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

Replies are listed 'Best First'.
•Re: Re: •Re: Re^2: Untainting safely. (b0iler proofing?)
by merlyn (Sage) on Jun 26, 2002 at 15:19 UTC
    This is a contrived example but: system( "touch file " $date ); where $date contained "01/01/2002|some nasty command" might cause trouble?
    Yes, so don't do that. Do: 
    system "touch", "file", $date;

    [download]
    like every Perl security guide says.

    And this just keeps illustrating the point. Yes, you can shoot yourself in the foot with Perl. But no amount of "generic data filtering" will help, because the most reasonable solution is user education and using the proper tools when you are performing potentially dangerous actions.

    What you are asking for is the equivalent of "bullets that don't sink in to human flesh, but can still kill the bear coming at you". Ain't gonna happen. No. You send the shooter to a safety class, where they learn never to point the business end at anything they don't intend to kill.

    Every one of your stated problems is a gap in education. Look, you learned how to type "p-r-i-n-t" somehow. If you learned just enough to be dangerous, then you are getting the outcome you deserve. If companies are funding only enough to be dangerous (as in not doing proper code review and security review), then they get an appropriate outcome.

    No amount of "filtering the data" will do anything more than just placating the idiots who don't place security in the same ballpark as correctness and on-time delivery.

    There are numerous security FAQs. There is a wealth of knowledge about good programming techniques and having a healthy distrust of data. It's not like any of this is any secret kept locked up in a dark tower. And when you can't afford to do the research, you must afford to rent that skill instead, by bringing in specialists for verification. It's as important as getting it working in the first place.

    Security is not something that can be "bolted on". It has to be designed in. Hiring someone that doesn't get that, is like hiring a Perl programmer who hasn't discovered hashes yet. It's just plain ludicrous.

    -- Randal L. Schwartz, Perl hacker

[reply]
[d/l]

      Ok Merlyn, I don't disagree with most of that, althought I did make some comments here(*see note below) which (IMO) somewhat deflate your proper code review and proper security review arguement a little.

      I still feel that something that must be done, project after project, and time after time within each project, is an ideal candidate for factorisation.

      I also feel that my personal lack of competence (which is confined to Perl, I have 20 years of typing p-r-i-n-t in other languages) is not, and should not be a factor in the discussion of whether the factorisation of--an often used, high priority, difficult to get right--part of the overall Perl/CGI project equation is a valid and valuable idea or not.

      Maybe NIH lives on.

      * Note: the referenced post is attributed to (as is the post to which you replied) AM cos i made a stupid mistake. I have asked the editors to correct this.

[reply]
        I still feel that something that must be done, project after project, and time after time within each project, is an ideal candidate for factorisation.
        And that's been done. And it's already available. It's called the "Perl Security FAQ" and the "Web Security FAQ". It's installed as humanware, not computerware, because the problem is not the programs, the problem is the programmers.

        No amount of Perl code would keep you from typing a single-arg system call. But 15 minutes staring at the Security FAQ, and bingo, you know not to type that.

        Why is that so hard to get?

        {sigh}

        -- Randal L. Schwartz, Perl hacker

[reply]

In Section Seekers of Perl Wisdom