> -----Original Message----- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2003 11:15 PM > To: Steven Brown > Cc: [EMAIL PROTECTED] > Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released
> On Thu, 14 Aug 2003, Steven Brown wrote: > > > -----Original Message----- > > > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, August 14, 2003 10:53 PM > > > To: Steven Brown > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: [PHP-DEV] Re: PHP 4.3.3RC3 Released > > > Unvalidated in what sense? We don't validate for > multiple queries > > > because we have no need to do so. > > > > Unvalidated in that I could modify the SQL query as my text > in the URL > > made it into the query unvalidated, unquoted, and unescaped. > > So? There is no possibility of an exploit here, so the > validation is adequate. The point was that even excellent programmers fail to validate the stuff that goes into SQL queries sometimes, not to hack php.net. Btw, it's also never adequate validation to let users inject their own SQL, even in a SELECT. They might add impossibly complex stuff to the where clause and cause your database to wedge for days, or add a 'or 1 = 1' to bypass security checks for information. However, it's relatively difficult to turn any arbitrary query into something really nasty. If you could chain queries without any safer PHP-provided interface, it would be trivial to inject whatever SQL you wanted via these common bugs. That's the other point. > And I have no idea why you copied the entire thread back to > me. I read it. Because I figured you wouldn't be pointing out that my php.net example isn't an exploit if you had read it. > We cannot possibly predict what user input > will be problematic in the various backends. The query > chaining char, if supported, is likely different from one > backend to the next, and chars that may be illegal in other > ways vary as well. On top of that, specific application > characteristics will introduce another set of dangerous data. Yes, which is why a command builder povided by the backend wrapper is a much safer solution than passing strings. To me, the desire to add chained queries to a backend forces the issue of developing and promoting such interfaces, as otherwise, there's going to be a lot of seriously insecure code out there all of a sudden. Why not have a builder for sqlite if you plan on keeping its chaining functionality? What's the desire to make it easier for folks to create big security holes instead of small ones - that no one wants to write the builder? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
