Marjolein Katsma wrote in reply to me:
> >> 1. To have SWISH-E execute a search, one needs to form a command line. That
> >One needs to fomr an argument vector.
> OK. (terminolgy...)
No, slight difference. Command lines get parsed, and parsing brings security
concerns. Create a vector and exec a program directly and no parsing
occurs. In C on Unix the man page for exec should explain this.
> >This need not be true. One can exec() the program directly, but this is
> >more complicated.
> I'd like to learn sometime. (Not now.)
Exec is not too hard, but exec()ing so you can read the output back is
> >perl -e 'system(q(ps|grep $$))'
> >perl -e 'open(FOO, q(ps|grep $$|));print <FOO>'
> OK. Like I said, I'm no Perl expert. I'm not even *using* Perl. But I did try.
> The first command results in:
> I'll admit I don't know what those responses mean. If the 'sh' in there
> means a Bourne shell is being used by Perl, fine.
> But... 1) I'm not using Perl, and 2) Roy Tennant's reply did not suggest
> anyone should or would, either. All he said was that a query string should
> be enclosed in quotes. (But I'm saying documentation for SWISH-E should not
> *assume* everyone is using Perl!)
The same thing can be done for exec() or system() equivilents in other
languages, including C.
> >You should be runing with perl in "taint" mode since that will make perl
> >complain loudly if you do insecure things. Use "#!/path/to/perl -T" as
> >the first line of the perl script. And read the perlsec(1) man page (or
> >"perldoc perlsec".)
> Are you saying whatever is generated by AutoSwish should be running in
> "taint" mode (whatever that is)?
Yes. Autoswish should generate scripts which use taint checking.
> (I'm not using Perl, and AutoSwish seems to be developed for people who
> don't write their own scripts: How would they know what to do or change?)
Autoswish should do this, then.
(I have not used autoswish.)
> Like I said, quoting the query string with just "" does NOT work in the
> plain C shell I'm using. I haven't tried single quotes yet, though. (But
> would single quotes, on their own, be any different than double quote on
> their own? By "on their own" I mean not enclosed/embedded in quotes of the
> other type.)
For the most part. You must make sure that people don't enter a query like
foo ' ; /some/path/command to run #
Or if they do, then you have to escape all the meta characters there.
> >> My literature suggests that Bourne-type shells are most usual on System V
> >> type Unix systems, while C-type shells are usually found on BSD type Unix
> >Virtually all modern Unices have both sh and csh. (Unless they have
> >bash and tcsh, which are free.)
> Do I "have" it? Maybe. Even probably, if the results from your test Perl
> commands mean what they suggest. BUT not everyone is in fact using Perl
> (I'm not). So not everyone is using sh!
I think it is standard for the C library call system() to use sh. Many
programs use system to run other programs: it is an easy function to use.
Perl's system() probably is just a simple wrapper around the C version.
Moral: the shell you use normally will not always be the shell used by
programs running programs on your behalf.
> "PHP Hypertext Preprocessor". A server-side embedded scripting language. To
> steal a competing product's slogan: "The document *is* the application."
> Depending on what you need to do, either PHP or Perl could be the best
> suited. But if you *can* use PHP, you often need fewer lines of code than
You might. I often write terse perl.
> (Please don't misunderstand me: I'm not against Perl in any way. But I do
> believe in using the right (or most efficient!) tool for the job, and I
> don't like learning too many things at once. Learning PHP and re-learning C
> while at the same time learning some Unix and web server configuration is
> about all I can handle in my own time right now. Perl's on my list for
> tackling later... And I also have a day-time job ;-) )
Perl has the advantage of being a very widely used language where security
problems will be found and fixed quickly. On the downside of that, it also
means that security holes will be more widely known by those who look for
security holes, so you have to keep up with updates.
> >statement might fail. Since there are known security holes in all
> >previous versions of perl, you should be running 5.004 anyway for
> >external services.
> Thanks for pointing that out. I do know I have "a" Perl 5 available but I
> don't know which subversion. I'm sure you have a special command that
> enables me to find out? I might want to use Perl in the future so it would
> be nice to know!
"perl -v" will give a short version message, "perl -V" will give a verbose
one. The built-in variable $] also has this, and you can do things like:
require 5.004; # die if the version is too old.
> Interpreting what you've said so far, it seems you do agree with me that:
> 1) the documentation of SWISH-E needs to be updated, and
> 2) the scripts generated by AutoSwish should be changed to make sure they
> are secure.
Yes to 2. I really can't remember the swish-e documentation all that well.
It has been some time since I read it.
> So I'll amend my suggestion (CONCLUSIONS point 3.): That AutoSwish use
> either your nice one-liner to escape all non-alpha-numeric characters in a
> query string, or use quotemeta() for the same purpose. Do you agree?
All input from the user should be scrutinized.
> >> And oh yes, you do of course realize that even people who can install and
> >> compile SWISH-E may *not* have the option of using a different shell?
> >If they don't have the option of using perl with the latest security
> >fixes then they will never be able to write a secure perl cgi.
> True - but like I said, not everyone is using Perl - let alone *writing*
nod. That just means they should keep on top of the security notices of
whatever they are using.
> It's all too often that I see "CGI" equated with "Perl", and it isn't of
People in the perl newsgroups hate this.
> SUMMING UP:
> I think you agree that:
> 1) the code generated by AutoSwish is not (always) secure, and
> 2) the SWISH-E documentation should *not* suggest that enclosing a query
> string in (double) quotes is all you need to do to make it work.
> Do you?
> >now working on an Apache/mod_perl version of his search.cgi
> (Now working on a new parsing algorithm for SWISH(-E or whatever) that
> correctly replaces entities and correctly parses HTML comments <grin>)
Sounds like I have the easier project. HTML comments are vicious.
Received on Sun Jul 19 12:09:17 1998