A security question??...generally speaking, how secure are hidden field values within the dynamic html page, I personally can't see how they may be manipulated, but I'm interested in your opinion...thanks Rob
There are methods of cracking passwords and username databases, as well as accessing codes for scripts and executing them.
Jul 25, 2000, 12:28 AM
Veteran / Moderator (8669 posts)
Jul 25, 2000, 12:28 AM
Post #3 of 11
Views: 2201
Hidden fields can easily be manipulated. All someone has to do is to save the source code for the page, enter it into a text editor and change the values of the fields. Then they open the changed text in their browser and hit the submit button.
For this reason, there are checks within DBMan for sensitive fields. For example, this is the reason the userid field is added within sub add_record and checked within sub modify_record. In my validation mod, the values are set within the db.cgi script, too.
If you have sensitive fields, you'll need to code them into the db.cgi script.
JPD
http://www.jpdeni.com/dbman/
For this reason, there are checks within DBMan for sensitive fields. For example, this is the reason the userid field is added within sub add_record and checked within sub modify_record. In my validation mod, the values are set within the db.cgi script, too.
If you have sensitive fields, you'll need to code them into the db.cgi script.
JPD
http://www.jpdeni.com/dbman/
Hi Carol..glad to hear your back is better...had back problems myself for years...can really demoblize you for sure...thanks for the reply re: hidden field security....I moved my sensitive hidden field in posting a record to add_form in db.cgi...works fine...am having a problem in the modify section...I want only the displayed form fields to be modifiable, but there are about six other fields values which can not be displayed in the mod form for the reasons you indicated...can you suggest away of including these field values in the mod db.cgi section...I've tried serveral methods that I could think of but none seem to work...thanks Rob
Jul 25, 2000, 4:45 PM
Veteran / Moderator (8669 posts)
Jul 25, 2000, 4:45 PM
Post #5 of 11
Views: 2181
Thanks, Rob. 
From all appearances, it was just something that was a little out of place. I felt it "click" back into where it was supposed to be and, after a couple of days for the muscles to get back to normal, everything was fine.
Regarding your problem -- here's the best way I can think of.
In sub modify_record, after
if ($data[$db_key_pos] eq $in{$db_key}) {
# If we have userid's and this is not an admin, then we force the record to keep it's own
# userid.
if ($auth_user_field >= 0 and (!$per_admin or !$in{$db_cols[$auth_user_field]})) {
$in{$db_cols[$auth_user_field]} = $data[$auth_user_field];
}
add the following for each field you want to preserve:
$in{'FieldName'} = $data[number of the field];
That will overwrite anything that is in the form field with whatever was already in the field in the database.
It just occurred to me that there could be a problem with this if you have more than one database which uses the same db.cgi file. If you do, you can set it up for multiple databases:
if ($db_setup eq 'database1') {
$in{'FieldName'} = $data[number of the field];
}
elsif ($db_setup eq 'database2') {
$in{'FieldName2'} = $data[number of the field];
}
You can stack up as many "elsif" statements as you need.
JPD
http://www.jpdeni.com/dbman/
From all appearances, it was just something that was a little out of place. I felt it "click" back into where it was supposed to be and, after a couple of days for the muscles to get back to normal, everything was fine. Regarding your problem -- here's the best way I can think of.
In sub modify_record, after
Code:
if ($data[$db_key_pos] eq $in{$db_key}) {
# If we have userid's and this is not an admin, then we force the record to keep it's own
# userid.
if ($auth_user_field >= 0 and (!$per_admin or !$in{$db_cols[$auth_user_field]})) {
$in{$db_cols[$auth_user_field]} = $data[$auth_user_field];
}
$in{'FieldName'} = $data[number of the field];
That will overwrite anything that is in the form field with whatever was already in the field in the database.
It just occurred to me that there could be a problem with this if you have more than one database which uses the same db.cgi file. If you do, you can set it up for multiple databases:
Code:
if ($db_setup eq 'database1') {
$in{'FieldName'} = $data[number of the field];
}
elsif ($db_setup eq 'database2') {
$in{'FieldName2'} = $data[number of the field];
}
JPD
http://www.jpdeni.com/dbman/
Jul 25, 2000, 5:16 PM
Novice (47 posts)
Jul 25, 2000, 5:16 PM
Post #6 of 11
Views: 2223
Hello Rob
Here is the complete script for "security". Nobody can run your database except on your own server.
So all your hard work will be protected! If somebody opens the file in there own browser and execute it ,they get a error. Yihaa!!!!!!
Put at the upper top of db.cgi:
@referers = ('www.yourdomain.com','yourdomain.com');(put this above $db_script_path = ".";)
Put in the sub main of db.cgi:
elsif ($in{'domain_error'}) { if ($per_view) { &html_domain_error; } else { &html_unauth; } }
Put at the top of sub add_record, sub mod_record, sub del_record and sub query in db.cgi:
&check_url;
Put in db.cgi at the bottom of the file:
sub check_url {
#--------------------------------------------------------------------
# Localize the check_referer flag which determines if user is valid.
local($check_referer) = 0;
# If a referring URL was specified, for each valid referer, make sure
# that a valid referring URL was passed to FormMail.
if ($ENV{'HTTP_REFERER'}) {
foreach $referer (@referers) {
if ($ENV{'HTTP_REFERER'} =~ m|https?://([^/]*)$referer|i) {
$check_referer = 1;
last;
}
}
}
else {
$check_referer = 1;
}
# If the HTTP_REFERER was invalid, send back an error. #
if ($check_referer != 1) {
&html_domain_error;
return;
}
}
Put in html.pl :
sub html_domain_error {
#---------------------------------------------------------
# Displays Error Message for View, Add, Delete, and Modify Forms
&html_print_headers;
print qq|
<html><head><title>$html_title: Bad Domain Referrer</title></head>
<body bgcolor="ffffff">
<div align="center"><center>
<table border="0" width="80%" cellpadding="2" cellspacing="0">
<tr><td valign="top">
<$font><b>$html_title: Bad Domain Referrer</b></font>
<p>
<$font>
This script cannot run from the following location:
<p><center><a href="$ENV{'HTTP_REFERER'}">$ENV{'HTTP_REFERER'}</a></center>
<a href="$db_script_link_url">click here to continue</a>
</font>
</td></tr></table></div></center>
</body></html>
|;
exit -1
}
This should do it !
greetings,
[removed by request]
The Netherlands (Europe)
Here is the complete script for "security". Nobody can run your database except on your own server.
So all your hard work will be protected! If somebody opens the file in there own browser and execute it ,they get a error. Yihaa!!!!!!
Put at the upper top of db.cgi:
@referers = ('www.yourdomain.com','yourdomain.com');(put this above $db_script_path = ".";)
Put in the sub main of db.cgi:
elsif ($in{'domain_error'}) { if ($per_view) { &html_domain_error; } else { &html_unauth; } }
Put at the top of sub add_record, sub mod_record, sub del_record and sub query in db.cgi:
&check_url;
Put in db.cgi at the bottom of the file:
sub check_url {
#--------------------------------------------------------------------
# Localize the check_referer flag which determines if user is valid.
local($check_referer) = 0;
# If a referring URL was specified, for each valid referer, make sure
# that a valid referring URL was passed to FormMail.
if ($ENV{'HTTP_REFERER'}) {
foreach $referer (@referers) {
if ($ENV{'HTTP_REFERER'} =~ m|https?://([^/]*)$referer|i) {
$check_referer = 1;
last;
}
}
}
else {
$check_referer = 1;
}
# If the HTTP_REFERER was invalid, send back an error. #
if ($check_referer != 1) {
&html_domain_error;
return;
}
}
Put in html.pl :
sub html_domain_error {
#---------------------------------------------------------
# Displays Error Message for View, Add, Delete, and Modify Forms
&html_print_headers;
print qq|
<html><head><title>$html_title: Bad Domain Referrer</title></head>
<body bgcolor="ffffff">
<div align="center"><center>
<table border="0" width="80%" cellpadding="2" cellspacing="0">
<tr><td valign="top">
<$font><b>$html_title: Bad Domain Referrer</b></font>
<p>
<$font>
This script cannot run from the following location:
<p><center><a href="$ENV{'HTTP_REFERER'}">$ENV{'HTTP_REFERER'}</a></center>
<a href="$db_script_link_url">click here to continue</a>
</font>
</td></tr></table></div></center>
</body></html>
|;
exit -1
}
This should do it !
greetings,
[removed by request]
The Netherlands (Europe)
Dec 14, 2000, 12:36 AM
New User (1 post)
Dec 14, 2000, 12:36 AM
Post #9 of 11
Views: 2123
I am been try similar scripts and found it works well in normal time, however when i try allow a remote user from a secure site to call the scripts which is simply define a new value to "@referers " the script blocks the calling. should any way to make the scirpt functional?
Jan 4, 2001, 7:04 PM
Novice (47 posts)
Jan 4, 2001, 7:04 PM
Post #11 of 11
Views: 2091
I'm replying to Hobo's #Post96112 re the sub check_url:
If some malevolent soul is using a modified form from the desktop,
it seems more likely than not that the $ENV{'HTTP_REFERER'} variable will be empty. So what I'd do is change
else {
$check_referer = 1;
}
to
else {
$check_referer = 0;
}
But first you need to check whether your server reliably sends the referer variable on its own.
If some malevolent soul is using a modified form from the desktop,
it seems more likely than not that the $ENV{'HTTP_REFERER'} variable will be empty. So what I'd do is change
else {
$check_referer = 1;
}
to
else {
$check_referer = 0;
}
But first you need to check whether your server reliably sends the referer variable on its own.