Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re: Re: Re: Re^2: Untainting safely. (b0iler proofing?)

by merlyn (Sage)
on Jun 26, 2002 at 15:19 UTC ( #177400=note: print w/replies, xml ) Need Help??

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

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

Replies are listed 'Best First'.
Re: �Re: Re: �Re: Re^2: Untainting safely. (b0iler proofing?)
by BrowserUk (Pope) on Jun 26, 2002 at 21:28 UTC

    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.

      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?


      -- Randal L. Schwartz, Perl hacker

        When something is difficult and/or dangerous and needs to be done repeatedly.

        When "human factors" mean that even the most god-like perfectionist can have a bad day.

        When simple economic factors prevent "proper code reviews and audit" with experienced and security trained peers. Or the hiring of expensive external expertise.

        When programmer turnover can be high.

        Simple logic and long-standing IT practice suggests that coding it once, getting it right, using it everywhere is the way to go.

        It is much easier to review code to check that the appropriate routine was called to sanitise all external data, than it is to inspect and verify that they way the sanitisation has been done is correct. Especially if the use of the sanitised data is to pass it to an external module - possibly third-party sourced.

        And I do get it? I just happen to think that you are wrong. {sigh}

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://177400]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (2)
As of 2021-07-25 00:24 GMT
Find Nodes?
    Voting Booth?

    No recent polls found