bbs problem

[John J. Trammell]

Here's what it looks like now, why isn't it printing it to the files...?

Thanks,
-Robin

#!/usr/bin/perl

#!/usr/bin/perl -T
use strict;
use warnings;

 

[Robin]

Got it working...thanks for all your great help...

 

[Tad McClellan]

Here's what it looks like now,

#!/usr/bin/perl

use warnings;
use strict;

&data_cgivars;

Have you been reading the followups to your postings?

If so, then why are you repeating the same mistakes?

If not, then why would we want to bother writing a followup
that will not be read?

 

[Tad McClellan]

Here's what it looks like now,

[ snip 200 lines of code ]


Have you seen the Posting Guidelines that are posted here frequently?

 

[Uri Guttman]

R> Got it working...thanks for all your great help...

got what working? your code had multiple bugs, security loopholes,
redundant cruft (CGI.pm AND lib.cgi???? do you wear a belt and
suspenders?), bad perl code, perl4 type calls, etc.

no one here will use this and given the many (mostly crappy) free bbs
things out there, this will only join that pile and rot away.

uri

 

[Robin]

R> Got it working...thanks for all your great help...

got what working? your code had multiple bugs, security loopholes,
redundant cruft (CGI.pm AND lib.cgi???? do you wear a belt and
suspenders?), bad perl code, perl4 type calls, etc.

I'd like to know one of the security holes. THanks- Robin

 

[Jay Tilton]

: So when someone
: types in spaces as their name it will work to reply to them

What does it do now, instead of "work to reply to them?"

: and on the
: "Reply to..." screen will actually stop showing the %A or whatever it is,

What exactly is "whatever it is?"

: what is that btw?

It sounds like you could be talking about a URI-escaped string, which
would presumably be taken care of by that mysterious "lib.cgi" the
program require()s. Is there a reason you're not using CGI.pm for this?

: Any help would be great.

You have not adequately described the problem. Posting the entire
program accomplished nothing.

No "use warnings;".
No "use strict;".
No checking open() calls for success.
No file locking.
No taint checking.

Ask Perl for help before asking people.

[snip code]
: open (POSTFILE, ">>BBSFILES/$FORM{'name'}.post");
[snip code]

Opening a file whose name includes a user-specified substring is a very
bad idea.

 

[Robin]

It sounds like you could be talking about a URI-escaped string, which

would presumably be taken care of by that mysterious "lib.cgi" the
program require()s. Is there a reason you're not using CGI.pm for this?

: Any help would be great.

You have not adequately described the problem. Posting the entire
program accomplished nothing.

No "use warnings;".
No "use strict;".
No checking open() calls for success.
No file locking.
No taint checking.

Ask Perl for help before asking people.

[snip code]
: open (POSTFILE, ">>BBSFILES/$FORM{'name'}.post");
[snip code]

Opening a file whose name includes a user-specified substring is a very
bad idea.

I didn't think of that, hmm...
-Robin

 

[Uri Guttman]

R> I'd like to know one of the security holes. THanks- Robin

you wrote it. you don't read perldocs (like the one that covers
security). you don't listen here.

that means security holes.

uri

 

[Robin]

you wrote it. you don't read perldocs (like the one that covers
security). you don't listen here.

that means security holes.

uri

I started reading the perldocs actually, not to defend myself or anything.

 

[Uri Guttman]

R> I started reading the perldocs actually, not to defend myself or
R> anything.

we told you to do that a long time ago. if you insist on doing
everything a week later, this will deteriorate to an even lower level
thread than i though possible.

do you realize how much good advice you have been ignoring? we even have
had a couple of testimonials from those who acted the same way a couple
of years ago and who have come to see the light of good perl
hacking. you claim you want to learn (and stop trying to teach/help. you
can't do that yet) but you don't do any learning stuff. have you read
the ENTIRE FAQ yet? that is the first thing you should do. read it ALL
and i mean ALL. skip if you don't understand something but don't ignore
it. you will now see the range of questions asked and answered and can
go back to find them later when you need.

uri

 

[Karlheinz Weindl]

Aren't those variables supposed to be set before the CGI object is created?

That should not make any difference since this is class data.

Karlheinz

 

[Jonathan Stowe]

what I'm trying to do is get this bbs.cgi to work better. So when someone
types in spaces as their name it will work to reply to them and on the
"Reply to..." screen will actually stop showing the %A or whatever it is,
what is that btw? Any help would be great.

I would fix the more fundamental problems first if I were you.

Chief among which are:

* No check on the success of file and directory opens and mkdir()

* No locking when writing to files

* Use of unchecked user input to create filenames

* No entity encoding of user input in HTML output

* Bad CGI decoding

At least one of these presents a serious security risk and should
preclude the use of the program on a server connected to the internet.

HTH

/J\

 

[A. Sinan Unur]

That should not make any difference since this is class data.

But sir, CGI.pm does the actual reading of the data when the first CGI
object is created.

Consider the following script:

#! /usr/bin/perl -T

use warnings;
use strict;

use CGI;
my $q = CGI->new();

$CGI:OST_MAX = 1;
$CGI:ISABLE_UPLOADS = 1;

unless($q->param('submit')) {
show_form($q);
} else {
process_form($q);
}

sub show_form {
my ($q) = @_;
print $q->header();
print <<HTML;
<html>
<body>
<form method="post">
<input type="hidden" name="hidden" value="0123456789">
<input type="submit" name="submit" value="Submit">
</form>
</body>
</html>
HTML
}

sub process_form {
my ($q) = @_;
print $q->header();
print <<HTML;
<html>
<body>
<p>Hi</p>
</body>
</html>
HTML
}

__END__

You can try this out at http://www.unur.com/cgi-bin/ctest_after. Then,
try the version where the limits are set before the first CGI object is
created at:

http://www.unur.com/cgi-bin/ctest_before

See the difference?

Sinan

 

[A. Sinan Unur]

You can try this out at http://www.unur.com/cgi-bin/ctest_after.

Actually, you can't. I have had my morning coffee since posting this, and
realized it is not a good idea to have a publicized vulnerability on my
site. You don't have to take my word for it though. You can either try out
the script yourself, or consult the CGI.pm documentation:

<blockquote>
You can use these variables in either of two ways.

1. On a script-by-script basis
Set the variable at the top of the script, right after the ``use''
statement:

</blockquote>

 

[David K. Wall]

R> Got it working...thanks for all your great help...

got what working? your code had multiple bugs, security loopholes,
redundant cruft (CGI.pm AND lib.cgi???? do you wear a belt and
suspenders?), bad perl code, perl4 type calls, etc.

no one here will use this and given the many (mostly crappy) free bbs
things out there, this will only join that pile and rot away.

Yeah, I wrote one, too, several years ago. I suppose I should take it off
the web. The main reason I don't is because the page has links to a taint
mode FAQ and a perl.com article about free CGI resources that recommends
nms scripts. At least my crappy BBS uses strict, warnings, taint mode,
CGI.pm, and *tries* to be secure and easily maintainable. But it still
sucks....

After I tried writing one I found that I dislike web BBSs. Someone
mentioned perlmonks as a good place to learn. I'm sure it is, but web BBSs
-- all of them I've seen, anyway -- have such horrible interfaces. "Whip
me, beat me, make me write programs with Notepad and use a web BBS!"

 

[Karlheinz Weindl]

But sir, CGI.pm does the actual reading of the data when the first CGI
object is created.

Consider the following script:

#! /usr/bin/perl -T

use warnings;
use strict;

use CGI;
my $q = CGI->new();

$CGI:OST_MAX = 1;
$CGI:ISABLE_UPLOADS = 1;

unless($q->param('submit')) {
show_form($q);
} else {
process_form($q);
}

sub show_form {
my ($q) = @_;
print $q->header();
print <<HTML;
<html>
<body>
<form method="post">
<input type="hidden" name="hidden" value="0123456789">
<input type="submit" name="submit" value="Submit">
</form>
</body>
</html>
HTML
}

sub process_form {
my ($q) = @_;
print $q->header();
print <<HTML;
<html>
<body>
<p>Hi</p>
</body>
</html>
HTML
}

__END__

So, what am I supposed see running this?
Definitely not the submit button and the 'Hi'.


Karlheinz

 

[A. Sinan Unur]

....

....


So, what am I supposed see running this?
Definitely not the submit button and the 'Hi'.

If you set the variables after creating the CGI object (as above), that is
exactly what you are going to see. Whereas if you set the variables before
creating the CGI object, you will see the submit button again.

Noe that I have removed the ctest_after script from my site because I do
not have a built in vulnerability advertised on the UseNet on my site.
You'll have to try the to versions out and see for yourself.

In fact, if you could be bothered to check the source code for CGI.pm
before posting assertions and challenges, you will see that content length
is only checked and STDIN only read in init and only if the CGI has not yet
been initialized. So setting the variables above after you have created the
first CGI object is futile.

This will hopefully be my last communication with you on this topic.

 

[Karlheinz Weindl]

A. Sinan Unur wrote:

[...]

If you set the variables after creating the CGI object (as above), that is
exactly what you are going to see. Whereas if you set the variables before
creating the CGI object, you will see the submit button again.

Sorry, did not mean to annoy you. I just did not get your point of
restricting the POST size to 1 byte at a first glance.

[...]

This will hopefully be my last communication with you on this topic.

Probably next time I should post under the pseudonym 'Robin' to receive
a less harsh tone from your side

bye
Karlheinz

 

[A. Sinan Unur]

If you set the variables after creating the CGI object (as above),
that is exactly what you are going to see. Whereas if you set the
variables before creating the CGI object, you will see the submit
button again.

Sorry, did not mean to annoy you. I just did not get your point of
restricting the POST size to 1 byte at a first glance.

[...]

This will hopefully be my last communication with you on this topic.

Probably next time I should post under the pseudonym 'Robin' to
receive a less harsh tone from your side

OK, I admit that was a little over the top. Apologies. No need to sink to
those lows

Sinan.