Re: $ENV{'CONTENT_LENGTH'} / STDIN

"Alan J. Flavell" <flavell@xxxxxxxxxxxx> wrote:
> On Fri, 23 Sep 2005, xhoster@xxxxxxxxx wrote:
>
> > "Alan J. Flavell" <flavell@xxxxxxxxxxxx> wrote:
> > >
> > > I'm nervous about the way that this is developing here.
> > >
> > > A server-side script should *know* what valid input it is expecting
> > > from a form submission.
> >
> > It should know the *general format* of the valid input it is
> > expecting. If it knew the actual valid input, there would be no
> > reason for a form in the first place.
>
> Sure. Can we skip the more extreme bits of pedantry please, and
> concentrate on the issues?

I believe that this is one of the issues. If you script properly deals
with hidden elements containing bits of state, then processing hidden
elements containing bits of state will done properly, and there is no
reason not to do it.


>
> > There is no reason that the general format of a valid input cannot
> > include a hidden element with a list of thingies. (Or a list of
> > hidden elements with one thingy each, depending on whether you are
> > looking at it after CGI.pm or before)
>
> Indeed; my concern was more with what the O.P seemed to be
> aiming to do when the parameter names came back.

I don't understand your concerns. He gave no inkling of what he was
going to do with them, so there was no greater cause for concern about them
than about every other aspect of writing a script.

>
> > > Some of the expected names may be present as name=value pairs and
> > > some may not. The program logic will need to cope with that
> > > anyway (since a server-side script needs to be battle hardened
> > > against anything that could be thrown at it, not merely against
> > > the expected inputs from the author-designed form) for security
> > > reasons.
> >
> > They way you cope with things for security reasons and the way you
> > cope with things for correctness reasons are very different.
>
> Even if there were no malicious users, there can always be mistakes,
> so I continue to counsel a *defensive* attitude to server-side
> programming.

I might agree if I had any idea what that means, or had any idea what it
had to do with my comment.


> A program which is absolutely correct but totally
> insecure may be perfect in the lab, but useless in the real world.

And a script which is absolutely secure but, in an attempt to forbid every
possible form for incorrectness allows nothing useful to be done, is
useless both in a lab and in the real world.

>
> > > This apparent attempt to persuade a server-side script to parse any
> > > damned form-control name that it might get,
> >
> > No persuasion is needed. CGI.pm will automatically parse any damned
> > form-control name that it might get. What you do with them, of
> > course, is up to you.
>
> I take your point. However, but "business end" of the script ought to
> *know* what it's doing, in terms of parameters,

And if the way that it knows what is doing in terms of some parameters is
by looking at the value of some other parameters, then it does, in fact,
know what it is doing in terms of parameters.


> Now, I'm not arguing that it's impossible to cope with that, just as I
> wouldn't argue that it's impossible in Perl to use variable variable
> names. But both are things that I reckon can be handled more safely
> by a different technique, and, if someone asks or discusses the issue,
> I'm going to feel it useful to advise the use of a safer method.

Except that you haven't actually advised of a safer method.

> > > seems to be well on the way to opening up, at the very least, a
> > > denial-of-service attack, if not worse, relative to the usual
> > > procedure.
> >
> > A denial of service attack just gives me the opportunity to fire,
> > and possibly prosecute, any malicious employee before they have the
> > chance to do something truly damaging. 20 minutes of downtime is a
> > small price to pay for getting rid of malicious personnel.
>
> By default I tend to treat intranets as just a special case of
> the wider (e.g world wide web) situation.
>
> If you want to deploy a deliberately insecure procedure

To me, something which is insecure allows people to see or change data they
have no write to see or change. A potential DOS is not insecure, merely
non-robust. Anyway, I don't go out of my way to open up scripts to DOS
attacks, I merely refrain from being paranoid about them. Imposing
arbitrary limits on the size of a problem people are allowed to submit
wastes far more of my predecessors time in coding the arbitrary
limitations, and then my time in recoding the arbitrary limitations every
time someone bumps up against them, plus the lost productivity of the
person who bumped up against them and needed to wait for me to change them,
than all accidental or intentional DOS attacks have ever caused me.

> in order to
> entrap a malicious employee, then IMHO you're discussing a very
> special case, that - paradoxically - needs *even better*
> "security-think" on the server side than the normal case. But let's
> not head down that particular track until we have to...?
>
> > Aside from which, I don't see how this method opens up any risk that
> > isn't already there. And what is "the usual procedure"?
>
> I meant having the evaluation phase of the script *know* what names it
> expects to find in name=value pairs in the submission, and process
> just those.

It needs to know how to know what names to expect. Sometimes that
knowledge can be directly hard-coded into the program, sometimes it can't.
When it can't, then one way around it that is to have it know how to look
up, in some other parameter what names it should expect, and have
hard-coded validation, rather than hard-coded names.


> One convenient approach is to have CGI.pm write the
> original form from the same script, so that the code is all kept in
> the same place.

That is completely orthoganol. If the CGI.pm using script has to
dynamically generate some of the element names, then some separate
invocation of that same script has to know what element names the prior
invocation generated. You could pass that knowledge through some kind of
sever-side storage keyed by cookie or hidden field, or you could pass that
knowledge directly through hidden field.

Sure, if you pass the data itself, it has to be validated. But then again,
if you pass only a key to the data, that also has be validated. If I have
to pass things through the client anyway, and validate it anyway, it is
often the case that I may as well do all that with the data itself rather
than some key into the data repository.


> > BTW, did you know that CGI.pm itself automatically prints out hidden
> > form elements containing the the names of the form's other elements?
>
> I perceive the trap that you're setting here. But all that CGI.pm
> does with them are to preserve them as sticky parameters, which is a
> linear process.

What makes you think whatever something other than CGI.pm does with them
won't be a linear process, also? Sure, you could make it nonlinear if you
tried, but you can write bad code in an infinite number of ways.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
.

Relevant Pages

  • Re: Is there a correct place to put javascript within a html file?
    ... The HTML specification tells you where script elements are permitted: ... script files have downloaded and if they're all in the head ... ... like the sensible thing to do; at least there's a reason for it. ... javascript is positioned just before the then the various html ...
    (comp.lang.javascript)
  • Re: Barbara Thiering Refuted!
    ... the particular script. ... John Byrne did. ... THIS HYPOTHESIS for the reason...what was the reason, ... capable of looking up the straight lines and crunching the numbers. ...
    (sci.archaeology)
  • Re: Barbara Thiering Refuted!
    ... the particular script. ... John Byrne did. ... THIS HYPOTHESIS for the reason...what was the reason, ... capable of looking up the straight lines and crunching the numbers. ...
    (sci.archaeology)
  • Re: Javascript Best Practices Document v1.0
    ... that document.formsis a bad practice when it is a DOM 2 HTML valid practice in XHTML ... The sole purpose of the unary plus operator is to convert its operand to a number. ... If the script cannot act, for whatever reason, the user is left with a link that doesn't do anything. ...
    (comp.lang.javascript)
  • Re: Linux Home Server HOWTO - Open For Review
    ... I did want to add some type of monitoring here, but I found the script ... Thats a fair call.. ... simple are a hard match to start with, thats the reason I at least ... I think it would be suitable to include a package ...
    (Fedora)