RE: Is it a security risk to use identical names for database fields and html forms?
At 12:53 PM 9/3/2001 +0100, yahoo wrote: Hi Gunther, yes, you are right - maybe my answer was a bit flippent - it was only meant to be a conversational addition to the thread rather than a definitive answer ;-) By access to the DB I meant a valid SQL login. I enjoyed reading that URL you posted. Seeing the SQL being returned to the web user for his/her inspection is certainly a most worrying situation! Once again it reinforces the golden rule that you should NEVER trust (or make unfounded assumptions about) user input. I think that dynamically created SQL statements (such as in the norm in MySQL) are very vulnerable to this kind of attack in contrasts to, say, using stored procedures. I enjoyed reading your post :-) Thanks! I also gave a talk on these issues at this past year's ApacheCon. I've placed the slides are up here: http://www.extropia.com/presentations/cgi_security_history.html Since me and Selena Sol have been around giving out open source web apps since 8 years ago (very early on the Web), we've of course seen the gamut of security holes, including those within our own past software. So this talk was really an attempt (within a tiny 45 minute talk) of going through common problems from a long time ago and linking them up to problems that are more recent and have gotten little publicity but 2 years down the road may be as rote as knowing that filenames need to be filtered. There's actually quite a bit of interesting stuff out there that has really only been discovered and publicized at all in the last year or two. Null byte is another huge issue few Perl programmers seem to know about/understand as it affects the file open() command in a subtle way yet I think it is not described in perldoc perlsec (it seems mostly focused on tainting and general validation issues). joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 01:15 To: yahoo; [EMAIL PROTECTED] Subject: RE: Is it a security risk to use identical names for database fields and html forms? At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially this
RE: Is it a security risk to use identical names for database fields and html forms?
--- Gunther Birznieks [EMAIL PROTECTED] wrote: There's actually quite a bit of interesting stuff out there that has really only been discovered and publicized at all in the last year or two. Null byte is another huge issue few Perl programmers seem to know about/understand as it affects the file open() command in a subtle way yet I think it is not described in perldoc perlsec (it seems mostly focused on tainting and general validation issues). If anyone's unfamiliar with the null byte problem, I have a brief description of it at http://www.perlmonks.org/index.pl?node_id=38548. 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: Is it a security risk to use identical names for database fields and html forms?
Hi Gunther, yes, you are right - maybe my answer was a bit flippent - it was only meant to be a conversational addition to the thread rather than a definitive answer ;-) By access to the DB I meant a valid SQL login. I enjoyed reading that URL you posted. Seeing the SQL being returned to the web user for his/her inspection is certainly a most worrying situation! Once again it reinforces the golden rule that you should NEVER trust (or make unfounded assumptions about) user input. I think that dynamically created SQL statements (such as in the norm in MySQL) are very vulnerable to this kind of attack in contrasts to, say, using stored procedures. I enjoyed reading your post :-) joel -Original Message- From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] Sent: 02 September 2001 01:15 To: yahoo; [EMAIL PROTECTED] Subject: RE: Is it a security risk to use identical names for database fields and html forms? At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially this person questioning why his colleague suggested doing this. Implementing old wive's tales of security (eg knock on wood, don't walk under ladders, untaint all your form input) without understanding the why behind it is sometimes just as bad as not having implemented the solution at all. For example, as I pointed out yesterday, if you obfuscate your form, you'll make creation and subsequent maintenance of the program much harder because it will be yucky to constantly convert from obfuscated form variable to real database field. Unclear code leads to bugs, and by probability some bugs are security bugs. Anyway, I apologize if I misunderstood the intent of your reply to the thread, but I personally had found it sufficiently vague that I wasn't sure what you were really advocating or thinking was the risk here. Later, Gunther -Original Message- From: Michael R. Fahey [mailto:[EMAIL PROTECTED]] Sent: 31 August 2001 13:33 To: [EMAIL PROTECTED] Subject: 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
RE: Is it a security risk to use identical names for database fields and html forms?
At 02:29 PM 8/31/2001 +0100, yahoo wrote: nah! what difference does it make? I mean, if they guy gets access to your DB server then he's gonna find out the fieldnames anyway! If he can't get access to your DB then what has he got?, a few POSSIBLE DB field names (i mean, how does HE know the names are real?) for him to attempt to recreate fragments of the data model pah! best of luck... joel Joel, while I do think that this is a nice succinct reply to the thread, I am not sure that it really uncovers the entire problem. It's a bit hard to understand what you mean in your post as you don't really qualify the phrase access to the DB. Sure, if I have a TCP stream to mySQL, it's possible to get anything. But access to a database through exploiting CGI is not always perfect and therefore being able to glean extra information is helpful to any cracker on the system. I do firmly believe that restricting the information you give the user about your system will help security, but I also think it is a matter of diminishing returns and would rather the user who asked the question focus on the things I highlighted in my post yesterday (eg quoting issues, data validation, etc). If the SQL is exploitable, then mucking about with the fields whose values are obvious candidates for being sent to the database makes a difference. But further, it does make a difference to know about the field naming when it comes to extrapolating how to generate the rest of the query. Do you really think that this is inconceivable? The following URL is a well-written account of rain forest puppy hacking into a BBS forum software by exploiting it's error handling routines to gather some bits of information about how the queries are being created and exploiting that information through the CGI script. http://www.wiretrip.net/rfp/p/doc.asp?id=42iface=2 Since I read this article and then in reviewing the security of other CGI scripts, I have found exploitable SQL code in at least several places. I guarantee that bad SQL coding is a problem for sure in the latest CGI scripts. But the degree varies from application to application. Just as seeing one cockroach in a kitchen actually entails a million more behind the walls, since reviewing CGI security is not a full time job for me (just an occasional if someone asks me), the fact I have seen this much exploitable code is an indicator to me that the problem is currently quite huge. In summary, I would heartily encourage careful best practices for SQL coding in Perl as I indicated yesterday and as RFP describes in the URL I gave above. And I would agree that the form variable changing names is probably not that useful to avoid attack, but I would not agree that it's entirely useless. I think risk assessment is a reasonable thing for this person to have asked about on this list, and shows a smart attitude towards security. Especially this person questioning why his colleague suggested doing this. Implementing old wive's tales of security (eg knock on wood, don't walk under ladders, untaint all your form input) without understanding the why behind it is sometimes just as bad as not having implemented the solution at all. For example, as I pointed out yesterday, if you obfuscate your form, you'll make creation and subsequent maintenance of the program much harder because it will be yucky to constantly convert from obfuscated form variable to real database field. Unclear code leads to bugs, and by probability some bugs are security bugs. Anyway, I apologize if I misunderstood the intent of your reply to the thread, but I personally had found it sufficiently vague that I wasn't sure what you were really advocating or thinking was the risk here. Later, Gunther -Original Message- From: Michael R. Fahey [mailto:[EMAIL PROTECTED]] Sent: 31 August 2001 13:33 To: [EMAIL PROTECTED] Subject: 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] _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/ -- To unsubscribe,
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]
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=Ovidcolor=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 presented. Here are two reasonable ones:
a) Use DBI's quote() method and run it through all the values to be set in
