an installer isn't needed..
thats a totally different thread (put it in modification requests)

this thread is about security, i think we should stick to the topic.
would the advanced coders be willing to help do security tests on the mods as they're released? or maybe create a new group that'll beta test/security check new mods?

within a few years if this isn't contained now, the board will be one security issue after another, if jelsoft are reading this, i believe it is in your best interests to tackle this problem head on and without hesitiation!

my 2 cents

all this won't happens if jelsoft take in considiration users needs and requests!! limiting the new release to the minimum is not not a solution either..for this we users need those hacks to fit our needs..even if they are full of bugs and security holes!! somehow we do not have choice either..way to go jelsoft!!!

Well according to Scott in a recent post at vB.com it'll be impossible to input malicious user input in future vB versions, so fear not :)

thats never the case, what about basic get functions that can be made to act differently, i can always post different variables.

You can use globalize with this:

STR_NOHTML

Those 2 functions you posted are built-in as part of the intrinsic vB globalize function.

Nice summary of the things globalize can do. :)

Add-on authors should utilize the built-in security vBulletin offers a lot more, rather than writing their own security checks.

Yeah I just went over every file in my new RPG version that didn't have globalize() already, and used it.

A side note about globalize():
If you want to run globalize() on an array, you have to skip using the "=>" stuff.
It would then be smart to run the functions quoted above on the variables as they are submitted into $DB_site->query() :)


You sayin that by using the htmlspecialchars_uni(trim()) there's no need for addslashes()?

Where are they all documented then ?

i'd like to know as well, i've done some searches but wound up empty

At this time the API isn't documented. It will be documented for the next release, however the usage of the inherent security features of vBulletin will change significantly so most hacks will need to be reworked anyway. We plan on providing full API documentation when the system is in a state to document.

As it is now, you need to go through the include folder and review the functions there to see what they do. Not optimal but that is what there is. Before the 3.0 release we concentrated on the Admin Control Panel Documentation because it would serve the most customers. When it came time to document the API enough significant changes were proposed and/or implemented that it was decided to postpone it.

when's the expected release date?
just a ball park figure?

Jelsoft will not comment on an estimated date - they did this with vBulletin 3, and when it came out later than expected, users became upset at them even though back then it was just an estimate. So now, I doubt that Jelsoft will even release a ball park figure, and that is a wise move.

is it vbulletin v4?
or vbuletin 3.0.4?

Last I heard it will be vBulletin 3.1 - but it may not. :)

I just refer to it as vB 3.x.0.

I think that's most likely, when looking at how they numbered vB2.
But what I heard about it makes it sound like an almost complete rewrite, which would make a v4 more likely....
Ah sod it, we'll see. All this thinking makes my skull hurt! :p

Higher...

Ooh... ;)

:speechless:

4.0 ?

3.2.0? ;)

This never got answered.
Anyone ?

Really you should use mysql_escape_string when cleansing input for the database :) That's PHPs native function. I can't understand why everyone is using addslashes still (myself included ;))

What about mysql_real_escape_string()? ;)

So basically as long as you are using something as input into an SQL query, it would be good to use mysql_real_escape_string() first, regardless of whether it is a Insert, Select or whatever kind of query ?

This is what PHP Devs have to say:

You are saying Addslashes is not a native PHP function?

AFAIK they are both native and almost identical (not mysql_real.. because that one also uses the database connection to take the character set used in account).

mysql_(real_)escape_string can be used since PHP 4.0.3, where addslashes was already available since PHP 3.

I want to know whether I should use mysql_real or keep using addslashes. Someone give me a definite "this or that" answer, or else someone will be in much pain ;)

Sorry I was tired last night when I made that post. I meant mysql_real_escape_string, and that addslashes won't properly escape everything pasted to an SQL query like mysql_real_escape_string will :)

Could someone write a tutorial on how to avoid such problems, maybe all the developers will follow it, I could sure use one.

here's a question

is it bad to do

I'm getting into the habit of uni'ing and adding the slashes to anything that isn't intvaled when inserted into the DB with user added stuff.

That is Ok

thanks :)

On a lighter note, this thread made me laugh a little!

Because I see many people who have loads of hacks installed. Then when a new version of vBulletin is released they sometimes remove there whole board because of mass hacking which they cannot revert back to upgrade to a new version of vBulletin. Then after doing a clean install of the new vBulletin version to plug possible security issues, they then re-hack there board all over again which could possibly add security issues all over again which they just upgraded to avoid.

Hahaha, Guess there must be method in that madness somewhere! :squareeyed:

That is odd, heh.

I personally only modify files if it's something I feel is worth it (and if it's no more than at least 3 or so files). I also try to avoid plugins and hacks that modify the database as best as possible too.

Modifying the database would not create a security problem in 99% of the cases. On the other hand 1 code edit (or even 1 plugin) could put your board wide open.

Avoidance of database changes are more of enabling me to easily upgrade more than anything else. I don't like wondering how anything database-wise would effect me later on. Just a thing of mine. :p

It's simple to me. RTFM
If it don't work uninstall it.

If you know how to fix it. PM / Email the creator how to fix.
Best of all, Backup so you can restore after you mess it up.

It's a NO BRAINER.

:D

We where talking security i think?