Started doing my first if...else chain in 2004, and released my first major vBulletin modification in August 2004 with the first version of the RPG Integration Hack.
I decided to write this because I am bored, and because I felt like sharing something that may be useful to people writing modifications to vBulletin code.
Now I realise that some of this may be obvious to you, but I am still young enough to remember myself asking questions that is now common sense to me.
Enough banter, onto the good stuff!
Use vBulletin's globalize() when parsing GET/POST data
This can be useful not only for avoiding SQL Injections, it also saves you trouble by running intval() on things that really HAVE to be of integer, etc.
If you find you cannot use globalize(), use it's functions anyways
For instance, I have an array consisting of arrays. I have an array of items, which each contains an array of values. All of this needs to be updated in the SQL.
Trying to use "=> INT" , "=> STR" or anything, results in errors.
You have to use blank datatype (IE no "=>").
It is then adviced to, inside the SQL query, run the functions globalize() normally would run.
The globalize() is located in the file /includes/functions.php(Thanks deathemperor)
When running globalize(), use "=> STR_NOHTML" if HTML is not needed.
Not too much to comment on this, the only possible security issue this would pose was if this function was run in a /modcp/ file, and the moderator had an urge to run some JavaScript he shouldn't... :ermm:
Always match up GET/POST values against stored values
For instance, if you have a Shop mod, do not directly update the user's cash based on the cost of the item bought.
Adding another check to a variable containing the amount of cash an user got will pevent users from being able to go into negative amounts.
Now you may think "but he *will* go into negative amounts so he *will* have to pay". True as that may be, if they exploited it once, do you think they will go "Ok, I got my item. I must now go pay the cost and never exploit this again"?
Neeeh...
Do not think POST is safe
Even if you use POST to prevent the above exploit, it will only fool the most basic of users.
Not only is it easy to make it accept GET values simply by using something like "script.php?select=name&cash=1000", but Firefox browser even has an extension called "Web Developer", which allows you to convert POST to GET and vice versa.
Never ever directly use variables containing strings in SQL queries.
addslashes() is your friend. If your completely unable to run anything of the above, at least run this. (Thanks KirbyDE)
Never ever assume an integer, especially one that comes from an input, is actually an integer.
intval() is also your friend. (Thanks sabret00the)
Ready to leave vB's safe haven?
Security Notes. This is a great piece of reading, thoroughly explaining all advice given and doesn't use language assuming we are all developers of the PHP program itself. (Thanks Guy G)
(This is possibly incomplete. I cannot think of anything more at the time of writing. Feel free to comment on things to add! )
globalize() is on functions.php I believe, it stores all golbal functions, if a functions was written for newpost then it should be in function_newpost.php or similar,
6. Never ever directly use variables containing strings in SQL queries. Always use addslashes().
Added, thanks
Quote:
Originally Posted by sabret00the
7. run integers through
PHP Code:
intval()
before you echo them out into the query
Same as above
Quote:
Originally Posted by deathemperor
globalize() is on functions.php I believe, it stores all golbal functions, if a functions was written for newpost then it should be in function_newpost.php or similar,
01-16-2005, 10:00 PM
)
01-17-2005, 09:16 AM
