Re: Re: Re: SQL query: are all results in one hashref key the same?

Slightly off topic... but since you mentioned it: PLEASE don't actually put literal values into your sql by string interpolation: $sql = "... thing_id = $thing_id ...";. Do it with placeholders and bind values. This can be more and less of a performance issue with different types of databases, but it is always a security issue. In some databases, I could specify a $thing_id of "5; drop table thing", and you'd be hating life. On databases where that sort of thing can't be made to work (like oracle, for example), I could still plant a denial of service attack by saying that $thing_id was

"(select min(thing1.thing_id)
from
    thing thing1,
    thing thing2,
    thing thing3,
    thing thing4,
    thing thing5,
    thing thing6,
    thing thing7,
    thing thing8,
    thing thing9,
    thing thing10
--look!  no 'where', clause this is a 10-way cartesian product of thin
+g!
)"
[download]

You can come back in a month when your database finishes processing that query.

------------
:Wq
Not an editor command: Wq

Comment on Re: Re: Re: SQL query: are all results in one hashref key the same? Select or Download Code

Replies are listed 'Best First'.
Re: Re: Re: Re: SQL query: are all results in one hashref key the same? by Cody Pendant (Prior) on Oct 12, 2003 at 04:40 UTC
Thanks for reminding me. I didn't understand the second example, but I sure as hell understood the first. I will certainly make sure that stuff is sorted out before the site becomes public. `($_='kkvvttuubbooppuuiiffssqqffssmmiibbddllffss') =~y~b-v~a-z~s; print` [download]	[reply] [d/l]
Re: Re: Re: Re: Re: SQL query: are all results in one hashref key the same? by etcshadow (Priest) on Oct 13, 2003 at 01:42 UTC
Well, the second example is just embedding a ridulous sub-query in your outer query. The way that SQL semantics work, if you say you are selecting from 2 tables and don't specify a correspondance between the rows of one and the rows of the other, then the result is the cartesian product of the rows in each table. If you do this with several tables (or, as in my example, several occurnces of the same table), then the resulting cartesian product is the size (in rows) of the product of the sizes (in rows) of all the tables. So let's say in our example that your table has only 100 rows in it... by joining it on itself 10 times over, you get one google (10 to the 100th power) of rows. By telling the database to take a minimum value out of those 1 google rows, you would lock up the database for, well, basicaly for ever, sorting through all of those rows. This would essenially deny service to your database until an administrator killed that query. Anyways, the point of the second example was: some database drivers, such as DBD::Oracle, do not allow you to embed multiple queries in a single DBI call, even if you put a semi-colon in there. I was just demonstrating a way that DBD::Oracle is still suceptible (spelling?) to attack through "SQL injection" (which, if I recall correctly, is the proper term for this form of attack). ------------ :Wq Not an editor command: Wq	[reply]