Go Back   vb.org Archive > vBulletin 3 Discussion > vB3 Programming Discussions
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Display Modes
  #1  
Old 10-22-2014, 05:52 PM
anolian anolian is offline
 
Join Date: Jun 2011
Posts: 22
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default are vb database permissions safe?

Hi

vBulletin support inform me that the vbulletin user needs almost all permissions on its the vbulletin database, apart form GRANT and those associated with views.

I am pretty ignorant re security, but doesn't this mean that by default, should someone hack vbulletin, they can do almost anything do the underlying database?

Does the default user really need this much power?

Can someone reassure me as to why this isn't dangerous please?

Thanks very much, Mike
Reply With Quote
  #2  
Old 10-22-2014, 06:53 PM
Lynne's Avatar
Lynne Lynne is offline
 
Join Date: Sep 2004
Location: California/Idaho
Posts: 41,180
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Yes, the mysql user that is assigned to the database does need to have all permissions granted. You may create a unique mysql user that is only to be used for that database. If someone manages to hack your server and get to your database, then you have bigger issues than worrying about just your vbulletin database. It is strongly suggested you make at least a daily database backup.
Reply With Quote
  #3  
Old 10-22-2014, 07:06 PM
Lynne's Avatar
Lynne Lynne is offline
 
Join Date: Sep 2004
Location: California/Idaho
Posts: 41,180
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

He said he was talking about database permissions, so I assumed he meant the mysql database user needing all permissions to the database. If that isn't it, he can always come back and clarify what he means.
Reply With Quote
  #4  
Old 10-22-2014, 07:29 PM
anolian anolian is offline
 
Join Date: Jun 2011
Posts: 22
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Thanks both

Yes - Lynne is correct (was my original email not reasonably clear?!).

It still seems odd to me. I take Lynne's point, but I know that at my previous workplace I would never have been allowed to create a web application user with so many permissions for normal everyday use. The DBAs and system people wouldn't have allowed it.

Perhaps they are overly paranoid - I really don't understand security enough to know!

Thanks again, Mike

--------------- Added [DATE]1414009829[/DATE] at [TIME]1414009829[/TIME] ---------------

Actually it could have been clearer, I guess!
Reply With Quote
  #5  
Old 10-22-2014, 07:54 PM
Zachery's Avatar
Zachery Zachery is offline
 
Join Date: Jul 2002
Location: Ontario, Canada
Posts: 11,440
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Which database permissions are you overly worried about, and why?
Reply With Quote
  #6  
Old 10-22-2014, 10:25 PM
anolian anolian is offline
 
Join Date: Jun 2011
Posts: 22
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Hi Zachery

Things like DROP, ALTER and CREATE bother me - perhaps unnecessarily, as I seem to be the only one! GRANT seems dodgy too (and since you said before it wasn't used, I will remove it).

But it does seem to me that in normal use (ie - a logged in user making and reading posts) the vBulletin app needs to do CRUD, but not much else. Doing updates and maintenance tasks clearly need more - but I would have expected a separate user with increased perms used for only those processes that need it.

I can't help wondering if this is an issue, as previous colleagues who know more than I have insisted on using accounts with the minimal perms for the tasks in hand, and have claimed this is more secure.

And, not being funny, but vB seems quite prone to security breeches... which is another reason why this seems suspiciously lax to me.

But as I said - I know very little about security and how that sort of stuff works - so am happy to accept I am probably wrong.

cheerio, Mike
Reply With Quote
  #7  
Old 10-22-2014, 11:38 PM
tbworld tbworld is offline
 
Join Date: Oct 2008
Posts: 2,126
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

@Anolian, you bring up some good points and correctly so. I am sure many of us have increased the security of vBulletin per our particular hosting environment, but vBulletin must write their software to run on a multitude of hosts and environments. This alone complicates the issue of security and ease of installation, let alone an advanced permission install.

As you have stated above, I believe you should not rely on PHP level permissions to control sensitive database options. As you have already figured out the solution for this is quite simple, it just makes it -- in my opinion -- too difficult for fist time users of the software and some of the environments out there. The modification system (which beginners use extensively) would be impossible to support. Anyway, good post. I liked it

Not that I know, but I am sure this is part of the thinking in the vb5 cloud release, you noticed they dropped the user API system for the release. Makes sense to me.
Reply With Quote
  #8  
Old 10-23-2014, 12:05 AM
Zachery's Avatar
Zachery Zachery is offline
 
Join Date: Jul 2002
Location: Ontario, Canada
Posts: 11,440
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

We use drop, create and alter, in the upgrade/maintenance/scheduled tasks.
Reply With Quote
  #9  
Old 10-23-2014, 06:29 PM
anolian anolian is offline
 
Join Date: Jun 2011
Posts: 22
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

@tbworld
Thanks for your comments. I take your points, but I still think vB could manage with 2 users, one with insert/update/delete on appropriate tables to allow users to register and contribute, with another with the more risky alter/drop/etc privileges.

@Zackery
I realise you use those permissions for admin tasks. My point was that they could be implemented in a more sophisticated manner (as is usually recommended), and that the security of the vB product might be improved as a result.

Cheerio!
Reply With Quote
  #10  
Old 10-23-2014, 06:49 PM
tbworld tbworld is offline
 
Join Date: Oct 2008
Posts: 2,126
Благодарил(а): 0 раз(а)
Поблагодарили: 0 раз(а) в 0 сообщениях
Default

Quote:
Originally Posted by anolian View Post
@tbworld
Thanks for your comments. I take your points, but I still think vB could manage with 2 users, one with insert/update/delete on appropriate tables to allow users to register and contribute, with another with the more risky alter/drop/etc privileges.
My point is that you could easily implement this yourself. I doubt vBulletin is going to modify the vb3 or vb4 product, but your suggestion is valid for vb5. You can easily deny those privileges (as you know) to the databases active user for vBulletin and grant raised privileges to another database user. In the most simplistic form of this: you would have to modify the config.php file so vBulletin new about this new privileged database user when you logged in to the ACP.

How much safer this all is... well that is a bigger debate.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 11:54 AM.


Powered by vBulletin® Version 3.8.12 by vBS
Copyright ©2000 - 2024, vBulletin Solutions Inc.
X vBulletin 3.8.12 by vBS Debug Information
  • Page Generation 0.09685 seconds
  • Memory Usage 2,250KB
  • Queries Executed 11 (?)
More Information
Template Usage:
  • (1)SHOWTHREAD
  • (1)ad_footer_end
  • (1)ad_footer_start
  • (1)ad_header_end
  • (1)ad_header_logo
  • (1)ad_navbar_below
  • (1)ad_showthread_beforeqr
  • (1)ad_showthread_firstpost
  • (1)ad_showthread_firstpost_sig
  • (1)ad_showthread_firstpost_start
  • (1)bbcode_quote
  • (1)footer
  • (1)forumjump
  • (1)forumrules
  • (1)gobutton
  • (1)header
  • (1)headinclude
  • (1)navbar
  • (3)navbar_link
  • (120)option
  • (1)pagenav
  • (1)pagenav_curpage
  • (1)pagenav_pagelink
  • (10)post_thanks_box
  • (10)post_thanks_button
  • (1)post_thanks_javascript
  • (1)post_thanks_navbar_search
  • (10)post_thanks_postbit_info
  • (10)postbit
  • (10)postbit_onlinestatus
  • (10)postbit_wrapper
  • (1)spacer_close
  • (1)spacer_open
  • (1)tagbit_wrapper 

Phrase Groups Available:
  • global
  • inlinemod
  • postbit
  • posting
  • reputationlevel
  • showthread
Included Files:
  • ./showthread.php
  • ./global.php
  • ./includes/init.php
  • ./includes/class_core.php
  • ./includes/config.php
  • ./includes/functions.php
  • ./includes/class_hook.php
  • ./includes/modsystem_functions.php
  • ./includes/functions_bigthree.php
  • ./includes/class_postbit.php
  • ./includes/class_bbcode.php
  • ./includes/functions_reputation.php
  • ./includes/functions_post_thanks.php 

Hooks Called:
  • init_startup
  • init_startup_session_setup_start
  • init_startup_session_setup_complete
  • cache_permissions
  • fetch_threadinfo_query
  • fetch_threadinfo
  • fetch_foruminfo
  • style_fetch
  • cache_templates
  • global_start
  • parse_templates
  • global_setup_complete
  • showthread_start
  • showthread_getinfo
  • forumjump
  • showthread_post_start
  • showthread_query_postids
  • showthread_query
  • bbcode_fetch_tags
  • bbcode_create
  • showthread_postbit_create
  • postbit_factory
  • postbit_display_start
  • post_thanks_function_post_thanks_off_start
  • post_thanks_function_post_thanks_off_end
  • post_thanks_function_fetch_thanks_start
  • post_thanks_function_fetch_thanks_end
  • post_thanks_function_thanked_already_start
  • post_thanks_function_thanked_already_end
  • fetch_musername
  • postbit_imicons
  • bbcode_parse_start
  • bbcode_parse_complete_precache
  • bbcode_parse_complete
  • postbit_display_complete
  • post_thanks_function_can_thank_this_post_start
  • pagenav_page
  • pagenav_complete
  • tag_fetchbit_complete
  • forumrules
  • navbits
  • navbits_complete
  • showthread_complete