[kh99]

Interesting idea - it definitely would help by making sure that any strings are escaped. However, I don't agree with your assertion that it's "a lot simpler". In fact, I find the second example to be a bit misleading because normally you would not collect all the records in an array, but instead you'd process them in a loop. So the second case using your product would require a for loop after it to process the records - the same loop that appears in the "common way" example. Also, collecting all the records in an array holds them all in memory at the same time, which could be an issue for a query that returns a lot of large records. One more thing that I admit is nit-picking - you probably would not need to worry about escaping a userid that was passed in $vbulletin->GPC['userid'] because you would have "cleaned" it using TYPE_INT (and you'd probably want to check for it being a postivie integer before going ahead with a query).

That said, it's a good idea, and there are probably people who aren't confident in their ability to ensure that all strings are escaped before using them in a query. Can't argue with the fact that that's been the issue in a couple of recent mod security problems, so using this would probably have avoided them.

Thanks for sharing this.

[vbresults]

Originally Posted by kh99

Interesting idea - it definitely would help by making sure that any strings are escaped. However, I don't agree with your assertion that it's "a lot simpler". In fact, I find the second example to be a bit misleading because normally you would not collect all the records in an array, but instead you'd process them in a loop. So the second case using your product would require a for loop after it to process the records - the same loop that appears in the "common way" example. Also, collecting all the records in an array holds them all in memory at the same time, which could be an issue for a query that returns a lot of large records. One more thing that I admit is nit-picking - you probably would not need to worry about escaping a userid that was passed in $vbulletin->GPC['userid'] because you would have "cleaned" it using TYPE_INT (and you'd probably want to check for it being a postivie integer before going ahead with a query).

That said, it's a good idea, and there are probably people who aren't confident in their ability to ensure that all strings are escaped before using them in a query. Can't argue with the fact that that's been the issue in a couple of recent mod security problems, so using this would probably have avoided them.

Thanks for sharing this.

It would make sure that any strings are escaped as you said. Most add-on queries that would cause a performance hit can have the limit adjusted or results paginated. Also, note that the read example was just that -- an example. I'll adjust it, but who's nit-picking now?

I really do hope coders start using this; it would change hundreds if not thousands of lives.

My pleasure to share.

[kh99]

Originally Posted by Lancerforhire

...Also, note that the read example was just that -- an example. I'll adjust it, but who's nit-picking now?

I knew it was just an example, I meant that *I* was nit-picking by mentioning it.

[vbresults]

Originally Posted by kh99

I knew it was just an example, I meant that *I* was nit-picking by mentioning it.

Ah, sorry!

[abdobasha2004]

your threads are just wonderful man !

[vbresults]

Originally Posted by abdobasha2004

your threads are just wonderful man !

Thank you

[Angel-Wings]

Hmm - wouldn't a good way be to use stored procedures ?

Then this problem is solved on the DB level instead of trying to escape some input - which won't hurt too for sure.

And the DB user would just need the EXECUTE permission, no more "dangerous" things like CREATE TABLE, DROP etc.

[vbresults]

Originally Posted by Angel-Wings

Hmm - wouldn't a good way be to use stored procedures ?

Then this problem is solved on the DB level instead of trying to escape some input - which won't hurt too for sure.

And the DB user would just need the EXECUTE permission, no more "dangerous" things like CREATE TABLE, DROP etc.

IIRC you'd need to create another connection to the DB and it's more complex. I could be wrong on the connection part, but either way it's far more complex.

[Andreas]

Prepared Statements (this efectively is smth. "like prepared statements light" ) are great, but hard to extend.

Hmm - wouldn't a good way be to use stored procedures ?

*eek*
You would need a stored precedure for everything but the kitchen sink to really prevent all prossible injections.

[Chris8]

Originally Posted by LancerForHireLLC

Download the product-extended_databases_ Xml and add it (extended_databases) as a product dependency. Yes; that's it!

I'm sorry, I' m not sure if I understood it well, the part with adding it as dependency.

To get it running I should upload it and install product-extended_databases-1.2.1.xml you've attached here and then in every mod which I would like to make sure that has strings escaped add it as dependency right into <dependencies>extended_databases</dependencies> tags. And that's it. Do I get it right?

[vbresults]

Originally Posted by Chris8

I'm sorry, I' m not sure if I understood it well, the part with adding it as dependency.

To get it running I should upload it and install product-extended_databases-1.2.1.xml you've attached here and then in every mod which I would like to make sure that has strings escaped add it as dependency right into <dependencies>extended_databases</dependencies> tags. And that's it. Do I get it right?

Put vBulletin in debug mode and add the extended_databases dependency to the product there, preferably with minimum version number 1.4. After you've done this, rewrite the queries using the format above.

---

On another note, 1.4 has been released!

[Dorgham]

I'm a big fan of your posts
And learn lots and lots
Thank you