Is it a security risk to use identical names for database fields and html forms?
Hi, I was looking at a perl script where the developer used different names for the incoming parameters and the database field names. He told me that this was done for security reasons-- to ensure that malicious users would not be able to discover the field names in the database being updated or queried. How dangerous is this? I think it would be easier to work with a hash of parameters from the input form. I'm using cg.pm, DBI, and postgresql. Thanks. Michael Fahey -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it a security risk to use identical names for database fields and html forms?
"Michael R. Fahey" wrote: > > I was looking at a perl script where the developer used different names > for the incoming parameters and the database field names. He told me > that this was done for security reasons-- to ensure that malicious users > would not be able to discover the field names in the database being > updated or queried. How dangerous is this? I think it would be easier to > work with a hash of parameters from the input form. i would think if you were using placeholders in your sql you wouldn't have a problem. from my experience, if you don't use placeholders then you'll have trouble. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
perl 5.6.1 and Apache problem
I have some Perl scripts that I use to run automated jobs. I launch the CGI
scripts with through a web browser and I use Apache. The scripts worked
correctly with perl 5.00503, but when I upgraded to perl 5.6.1, the scripts
do not work the same. The Apache version is 1.3.12. My server is running
RedHat 6.1, linux kernel 2.2.12-20.
I have 3 scripts, parent.pl, child.pl and grandchild.pl. They are in
/home/httpd/cgi-bin. I have simplified the scripts for testing. With a web
browser I go the url
http://myserver/cgi-bin/parent.pl?job=test&title=testrun. I stop the
browser after I went to that url (I do not wait for it to timeout).
Parent.pl execs to child.pl. Child.pl forks and then execs to
grandchild.pl. Grandchild.pl just sleeps forever. With perl 5.00503, when
I do 'ps auxw' on the server I would see the pids for child.pl and
grandchild.pl. With perl 5.6.1, about 10 minutes after the scripts started,
when I do 'ps auxw' on the server, I no longer see the child.pl pid. I need
the pid for child.pl because I have another script that polls the system for
that pid to verify the script is still running and notifies me when it
stops.
I have changed the timeout setting in the Apache conf file
(/etc/httpd/conf/httpd.conf). It defaults to 300 seconds, but I tried
changing it from 10 all the way to 10. I still get the same results.
About 10 minutes after the browser session ends, the pid for child.pl
disappears.
Is there any way to resolve this? Did anything change if fork or exec in
5.6.1?
Thanks in advance,
Andy
Here's the 3 scripts:
parent.pl
-
#!/usr/bin/perl
use CGI_Lite;
my ($cgi, $data, @task);
$cgi = new CGI_Lite ();
$data= $cgi->parse_form_data ();
$task[0] = $$data{'job'};
$task[1] = $$data{'title'};
print "Content-type: text/html\n\n";
print "Dummy Test";
exec '/home/httpd/cgi-bin/child.pl', @task;
print "";
exit 0;
-
child.pl
-
#!/usr/bin/perl
my ($p1, $p2);
$p1 = $ARGV[0];
$p2 = $ARGV[1];
RunProcess('/home/httpd/cgi-bin/grandchild.pl') ;
# RunProcess: Similar to the "system()" call, only this code does not block
# certain signal handling such as SIGINT, SIGHUP, SIGQUIT giving us the
ability
# to kill the process (without turning into a zombie) if we "system" out
# another script/binary.
sub RunProcess(@)
{
my $ProgramName = shift(@_);
my @Arguments = @_;
my $pid = 0;
my $ChildPid = 0;
my $length = 0;
# (Striped this code out of Programming Perl by O'Reilly & Assoc., Inc)
if ( $pid = fork ) { # fork
# Parent process
$ChildPid = $pid;
push @childPidList, $ChildPid;
waitpid $ChildPid, 0;
@childPidList = RemoveElement( $ChildPid, @childPidList );
} elsif (defined $pid) { #Child
# Child Process
sleep 10 ;
unless (exec $ProgramName, @Arguments)
print "Failed to 'exec $ProgramName @Arguments'\n";
exit 0;
}
} else {
print "Couldn't Fork, continuing";
return 0;
}
return 1;
}
sub RemoveElement($@)
{
my $id = shift(@_);
my @list = @_;
my $count = 1;
my $listLength = $#list + 1;
foreach $item ( @list ) {
if (( $item == $id ) && ( $count <= $listLength )) {
splice( @list, $count-1, 1, splice( @list, $count ) );
}
$count++;
}
return @list;
}
-
grandchild.pl
-
#!/usr/bin/perl
while (1) {
sleep 5 ;
}
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it a security risk to use identical names for database fields and html forms?
--- "Michael R. Fahey" <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I was looking at a perl script where the developer used different names
> for the incoming parameters and the database field names. He told me
> that this was done for security reasons-- to ensure that malicious users
> would not be able to discover the field names in the database being
> updated or queried. How dangerous is this? I think it would be easier to
> work with a hash of parameters from the input form.
>
> I'm using cg.pm, DBI, and postgresql.
>
> Thanks.
>
> Michael Fahey
Hi Michael,
Great question! This raises some security issues that many people just don't consider.
Wether or not this is a security risk depends upon exactly how you use the incoming
data. Let's
look at a short script that does this horribly, horribly wrong:
#!/usr/bin/perl -w
use warnings;
use strict;
use CGI qw/:standard/;
use DBI;
my $dbh = DBI->connect( 'dbi:ODBC:stuff', 'name', 'password',
{ RaiseError => 1} ) or die DBI->errstr;
my %data = map { $_, param( $_ ) } param();
my ( @fields, @values, $name, $value );
while ( ($name, $value) = each %data ) {
push @fields, $name;
push @values, $dbh->quote( $value );
}
my $sql = "INSERT INTO theTable (" .
join ( ",",@fields) .
") VALUES (" .
join ( ",",@values ) .
")";
print header,
start_html,
p( $sql ),
end_html;
So far, everything might look okay. The developer was even security conscious and
quoted the
values. Imagine what happens if this script is called with the following URL:
http://www.somehost.com/cgi-bin/db.cgi?name=Ovid&color=red
You get back a nice Web page with the following SQL:
INSERT into theTable ( name,color) VALUES (Ovid,red)
That's all well and good. Now, let's alter the URL slightly:
http://www.somehost.com/cgi-bin/db.cgi?name%29%20VALUES%20%28%20%27Ovid%27%20%29%3BDROP%20TABLE%20theTable%3BINSERT%20INTO%20theTable%20%28name=Ovid
Hmm, that's a bit more complicated. I wonder what the SQL is?
INSERT INTO theTable (name) VALUES ( 'Ovid' );DROP TABLE theTable;INSERT INTO
theTable (name)
VALUES ('Ovid')
Oops. We might lose that table. Now, by crafting a good query string, we can attempt
to execute
arbitrary SQL against the database (there are many, many variations of this attack).
These
attacks are kind of tricky because you usually need to craft the URL in such a way as
to ensure
that *all* of the SQL is valid at the time it's evaluated, but it's still a possible
exploit.
There are ways to make this secure and still use the field names, but I wouldn't
suggest it. While
I am not an advocate of Security by Obscurity, I do advocate not revealing information
that you
don't need to reveal.
Cheers,
Curtis "Ovid" Poe
=
Senior Programmer
Onsite! Technology (http://www.onsitetech.com/)
"Ovid" on http://www.perlmonks.org/
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Does Perl2Exe remove the Compilation Phase?
Recently, I've been reading a lot into CGI performance and how to reduce the amount of memory and time it takes to run a CGI based application. The number one thing to attack is the start time - the half second or so that Perl looks at the script and compiles all the modules and that sort of junk. Now, knowing that skipping the compilation phase will not solve all my problems (since most are related to the CGI environment), if I Perl2EXE'd for Linux my CGI programs, would that save me a half second or so (or whatever the startup costs are)? Or does that merely embed the interpreter so that the startup / compilation phase still happens? -- Morbus Iff ( i am your scary godmother ) http://www.disobey.com/ && http://www.gamegrene.com/ please me: http://www.amazon.com/exec/obidos/wishlist/25USVJDH68554 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it a security risk to use identical names for database fields and html forms?
At 01:55 PM 8/31/2001 -0700, Curtis Poe wrote:
>--- "Michael R. Fahey" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I was looking at a perl script where the developer used different names
> > for the incoming parameters and the database field names. He told me
> > that this was done for security reasons-- to ensure that malicious users
> > would not be able to discover the field names in the database being
> > updated or queried. How dangerous is this? I think it would be easier to
> > work with a hash of parameters from the input form.
> >
> > I'm using cg.pm, DBI, and postgresql.
> >
> > Thanks.
> >
> > Michael Fahey
>
>Hi Michael,
>
>Great question! This raises some security issues that many people just
>don't consider.
This is true. Kudos to any beginner asking about security at all!
>Wether or not this is a security risk depends upon exactly how you use the
>incoming data. Let's
>look at a short script that does this horribly, horribly wrong:
>
> #!/usr/bin/perl -w
> use warnings;
> use strict;
> use CGI qw/:standard/;
> use DBI;
>
> my $dbh = DBI->connect( 'dbi:ODBC:stuff', 'name', 'password',
> { RaiseError => 1} ) or die DBI->errstr;
>
> my %data = map { $_, param( $_ ) } param();
>
> my ( @fields, @values, $name, $value );
>
> while ( ($name, $value) = each %data ) {
> push @fields, $name;
> push @values, $dbh->quote( $value );
> }
>
> my $sql = "INSERT INTO theTable (" .
> join ( ",",@fields) .
> ") VALUES (" .
> join ( ",",@values ) .
> ")";
>
> print header,
> start_html,
> p( $sql ),
> end_html;
>
>So far, everything might look okay. The developer was even security
>conscious and quoted the
>values. Imagine what happens if this script is called with the following URL:
>
> http://www.somehost.com/cgi-bin/db.cgi?name=Ovid&color=red
>
>You get back a nice Web page with the following SQL:
>
> INSERT into theTable ( name,color) VALUES (Ovid,red)
>
>That's all well and good. Now, let's alter the URL slightly:
>
>
>http://www.somehost.com/cgi-bin/db.cgi?name%29%20VALUES%20%28%20%27Ovid%27%20%29%3BDROP%20TABLE%20theTable%3BINSERT%20INTO%20theTable%20%28name=Ovid
>
>Hmm, that's a bit more complicated. I wonder what the SQL is?
>
> INSERT INTO theTable (name) VALUES ( 'Ovid' );DROP TABLE
> theTable;INSERT INTO theTable (name)
>VALUES ('Ovid')
>
>Oops. We might lose that table. Now, by crafting a good query string, we
>can attempt to execute
>arbitrary SQL against the database (there are many, many variations of
>this attack). These
>attacks are kind of tricky because you usually need to craft the URL in
>such a way as to ensure
>that *all* of the SQL is valid at the time it's evaluated, but it's still
>a possible exploit.
>
>There are ways to make this secure and still use the field names, but I
>wouldn't suggest it. While
>I am not an advocate of Security by Obscurity, I do advocate not revealing
>information that you
>don't need to reveal.
An important additional point is that simply renaming your form parameters
to be different from the database, you would still usually have a 1 to 1
mapping from the form to the database field name somewhere in your code.
So the above code that was given as an example could possible screw things
over for you even if you renamed the variables. And conceivably, you could
play tricks if you knew more about the database to issue alternative
queries in-line if a section of the CGI script is issuing queries itself.
While it is conceivable that security through obscurity has SOME value, I
am not sure that in what might be a large program that such a mapping helps
your programmer's thinking process in terms of writing and maintaining the
code later.
If the form vars are renamed with an obvious prefix like fname in the
database becomes form_fname then it should be obvious to a cracker that
form_ is a standard prefix. So the best way to rename the variables is
fairly randomly. But this will suck for your maintenance of the code. I
suppose you could have a filter function that takes CGI.pm and remaps the
form values inside of it, but it's still harsh on the forms developer for
debugging and always remembering the mapping. What a yucky thing to have to
work on then!
I would tend, therefore, to shy away from security through obscurity in
this case and focus more on how to make the SQL secure itself. As has been
pointed out in the last post well, validation of input is very important.
For an introduction of the basic issues, any documentation having to do
with taintmode is quite reasonable to read. eg
http://www.gunther.web66.com/FAQS/taintmode.html
Also, if you are writing SQL code, you should definitely consider the
following three issues:
1) The quoting issue was discussed by the previous poster.
But there was no solution
Re: Does Perl2Exe remove the Compilation Phase?
Morbus Iff <[EMAIL PROTECTED]> wrote: > Recently, I've been reading a lot into CGI performance and how to > reduce the amount of memory and time it takes to run a CGI based > application. The number one thing to attack is the start time - the > half second or so that Perl looks at the script and compiles all the > modules and that sort of junk. >From an email correspondence I had with ActiveState: Unfortunately, PerlEx does not currently allow you to use taint checking. However, it is being considered as a feature of the next PerlEx release, which is scheduled to occur in the couple of months. That was several months ago and, as far as I know, taint checking is still not supported. This alone is reason enough for me to rule out PerlEx. Oh, and the $395.00 *per CPU* is pretty steep considering that the alternatives are free, well-documented and much more secure. Cheers, Curtis "Ovid" Poe = Senior Programmer Onsite! Technology (http://www.onsitetech.com/) "Ovid" on http://www.perlmonks.org/ __ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Perl2Exe remove the Compilation Phase?
> "Morbus" == Morbus Iff <[EMAIL PROTECTED]> writes: Morbus> Recently, I've been reading a lot into CGI performance and how to Morbus> reduce the amount of memory and time it takes to run a CGI based Morbus> application. The number one thing to attack is the start time - the Morbus> half second or so that Perl looks at the script and compiles all the Morbus> modules and that sort of junk. Then use mod_perl. That's much better than any "create a separate executable for every different Perl program" solution. see perl.apache.org et. seq. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
