The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#1
|
||||
|
||||
Security Mod
I am planning to work on a secrity mod for vbulletin but i wnted to get some input from more seasoned dev's here on vb. My plan is to create a file locking system by using the
$lockFileCommand = flock($showthread, $lockWrite && $lockRead); but i`m not sure if this method wold really work. I was going to save the file locking commands under the variables $lockWrite and $lockRead to make it easier to use them in my scripts. My question is would this work to lock the files and give only the vbulletin files access to read and write them. I was going to do a similar deal to the define('THIS_SCRIPT', 'showthread'); but instead use define('VB_SCRIPT', 'showthread'); and an included file to each script so that if the above is defined it can read and even write to the other files that have it defined. I`m wondering would i be wasting my time doing this or would it actually work on preventing people from hacking sites? please voice your input on this. |
#2
|
||||
|
||||
Greetings, fellow Naruto fan. I don't think that the flock function does what you think it does... It locks a script from being read or written to all together. Until you unlock it. The only reason this function exists is if you're doing large data crunching and don't want anyone else to mess with your data AS you are reading it. It's not for security.
Locking any of the .php files from being read will be disasterous, since that particular page (or backend script) will instantly stop working for everyone except the person that initiated the lock. And until that person unlocks the file, no one else can use it. You'd constantly see "page cannot be found" errors. What you probably had in mind was locking the file, and then unlocking the file automatically after the page is done loading - but in real time if two people loaded that script at the same time one of them would lock the other one out. If you have an intensive script, like if you're updating the search index - or if you have a frequent cron job, your end users will get stopped in their tracks. Consider if you have two users adding a new post at the same time - if one gets locked out they will see the "page cannot be found" error. Their browser might not be capable of just click "back" to restore the text they had typed (that would be frustrating). On a public website, no files should be open for writing anyway. The next biggest problem you have is with the unlock. By default, Apache and IIS run all php scripts as a single user on the server. Anyone viewing a script could execute the unlock function if the unlock condition isn't properly written. Essentially this would make your initial lock worthless. Unless you've customized your apache or IIS such that users have to log into the server with server-level credentials (aka. turned off "anonymous access" to the website) flock is worthless for security. |
#3
|
|||
|
|||
What is it exactly that you want your script to protect against?
|
#4
|
||||
|
||||
I know what flock does lol I wonted to make it so all files are unlocked only to vbulletin. So that any remote script woldnt be able t access them. So it would basiclly add the names of the scripts so that if the defined isnt there the script gets locked from being accessed.
|
#5
|
||||
|
||||
Nah, the flock will lock out based on user accounts on the server - not based on which script is what.
If you want to be anal about it, edit your global.php file with something like: Code:
if(!defined('MY_SCRIPT_CHECKING_VARIABLE')) { die('Hacking attempt!'); } Code:
define('MY_SCRIPT_CHECKING_VARIABLE', true); However, it's not exactly practical because you have to edit every single php file, and you have to keep doing it for every single upgrade. |
#6
|
||||
|
||||
vBulletin already checks for VB_AREA and THIS_SCRIPT.
|
#7
|
||||
|
||||
Yeah, but those are default to the scripts. Its easy to add a "VB_AREA" and "THIS_SCRIPT" variable in and then include the global.php, as well as anything else they want. A potential hacker wouldn't know the customized variable. This is really only a concern for other scripts accessing vBulletin - like for example if someone is on a shared host and the file permissions are not set properly, someone else on the same server could utilize/execute the scripts of other users (I believe that GoDaddy's hosting service had this problem for awhile, not sure if it still does or not).
So by making a custom variable for himself, he ensures that it's only his approved scripts that can call global. One idea that Jelsoft could use is if they use this technique but with customer numbers. Consider: every php file will be altered on the fly at download time with the appropriate customer number at the top of the file. Why not take it a step further and make it into a variable that is checked for security? I know that the customer number is checked when you enter the upgrade system. The only downside is that the modification system would be largely broken - all custom .php files would have to be altered to follow the new standard, and I don't think there's a way of modifying the addon/hack .php files on the fly at download so the modifications to the addon/hack .php files would have to be done by the users. But at least it would be that much more secure... It's up to jelsoft if they want to do that. |
#8
|
||||
|
||||
No your miss understanding me I wasnt going to use the file lock function to lock all files instead i was only going to set its so each script has the above defined in my first post and then $flock(); with LOCK_UN so there all read only and have it so that if a script is trying to write to another file it would first be checked to see if it had the defined at the top and a commented out code like //000111001000 and if it did it would then allow the script to write by switching it to the LOCK_UN to LOCK_EX and then it would close the file once the script was done excetuting. That way only your scripts would be allowed to have write access. But i`ll instead use your idea saves me the trials of coding the system and testing and debugging.
Thanks TigerC10 |
#9
|
||||
|
||||
Oh, so you mean like... Say you store your avatars in a directory instead of in the database. You would want to use your lock unlock idea to prevent writing to the directory unless the script has permission?
|
#10
|
||||
|
||||
Yup every script would use the LOCK_UN and it wold alll be controled by the admin cp since most scripts that do writing use str_replace and preg_replace so it would first check the script that is used to execute that command aka the plugin engine to see if its actually the plugin system doing the commands or any other script that belongs to the forums owner. If it did have the defined and the code which would be generated at random or it could check the pages for the vbulletin id number that each one has at the top, well some pages have it using preg_find and if it did have it then the file would be opened using str_replace to replace the LOCK_UN and chnage it to LOCK_EX and then when its been comfirmed to have executed then it would replace the LOCK_EX with LOCK_UN. That way only your scripts can write to another script. Every script would be put inot and array like they do for THIS_SCRIPT so its stored in memory what scripts are what. I would say using array_merge but someone said theres an easier way like how they do it for the template cache.
|
Thread Tools | |
Display Modes | |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|