Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

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

by tadman (Prior)
on Jun 25, 2002 at 23:55 UTC ( #177237=note: print w/replies, xml ) Need Help??


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

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.
  • Comment on Re^2: Untainting safely. (b0iler proofing?)

Replies are listed 'Best First'.
Re: Re^2: Untainting safely. (b0iler proofing?)
by merlyn (Sage) on Jun 26, 2002 at 00:02 UTC
    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

      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

        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

      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.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (2)
As of 2021-07-25 00:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found

    Notices?