• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Lack of interest Readers & Writers


Active member
As I am still working on this with my VB installs this suggestion may be a little incomplete.

All software eventually has security flaws. With add-ons, this becomes even more of an issue. For example, vbseo is constantly patching holes. I administer almost 40 forums and when they start getting hacked, it creates a lot of work and costs my clients serious money. I have begun working on proactive solutions to limit attack vectors. One that we are working on now is showing promise: Create two mysql users and limit the privis of the default mysql user (default user), and give more permissive privis to the second mysql user (let's call it the admin user).

The default user cannot write to certain tables, such as templates, plugins, settings, etc.. If the user tries, mysql throws a permissions error. So even if there is an exploit they cannot insert any code into these tables (providing they are not in the admincp). As we see with many of these hacks, one of the first things they try to do is spread their malware to the audience via the templates or plugins. If I didn't have to rely on hook locations, I could eliminate more tables (i.e. datastore).

In my model, the admin user only connects to the database when in the admincp, or in a cron job.

I know I am speaking in terms of vBulletin, but that is all any of us here except the staff have to illustrate this kind of suggestion. :)


No, not really. I am still working on the vBulletin Audit product that scans your account passive and returns with an output of concerns and suggestions. (a 0.29 alpha is out on vborg somewhere) and suggestions like these take it a step further. I find it quite interesting!


Active member
It is coming along.. I am testing it now now on a small live site. If built into the code (instead of a plugin) it could be much more powerful. Right now I am protecting the plugin, template, and setting tables.


Active member
I would not say easily.. The time we got hacked I found the exploit in vbseo. It was a pretty crafty exploit and must have taken some time to ferret out. What motivates someone to spend so much time looking for holes? Who knows...


Active member
I don't think they are just bored.
However we will have to look at the code to know how this can be done.
I think that if xf uses some kind of class to query the database, you can check it before the query runs and use a limited privileges users for every query that preg_match "^SELECT".
Not sure, but usually hackers uses some kind of mysql comment to insert the bad code in the query, however if the query starts with "SELECT" you can always limit what's happening ;)
Not even sure if i've explained.


Active member
There is no way to "transform" it if you mean overload it somehow. They can however change a query or append to one.. Example: SELECT * FROM WHEREVER.. A hacker could: SELECT * FROM WHEREVER; INSERT INTO WHEREVER.. A MySQL user who cannot use select is dead in the water..


Active member
That is what i tought.
Since that xf dosen't uses this sintax:
select *; insert *
you can restrict the queryes that starts with select to a read only user.