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=42&iface=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, 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, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
