Securing Dadabik

  • Thread starter Marco Tulio Cicero de M. Porto
  • Start date
M

Marco Tulio Cicero de M. Porto

Guest
Hello!

My name is Marco Tulio, I'm from Brazil and quite a new Dadabik user. And first of all, I would like to say that Dadanik is very good program that helped me a lot. But...

...the thing is that Dadabik, as a database interface, gives you direct access to the database you're using. I was just following the "Dadabik on the web" link (on this website) when something occured me: What if someone got into my admin.php page and uninstalled the tables I got into Dadabik, or changes the way the page appears to users, or even delete data from my DB?

Well, if my database user has all privileges, then anyone that could have direct access to my admin.php could erase all my database.

Also, if my admin.php has permitions set to everyone (execute, write, read) then I also have a problem since anyone could make any kinda change on my forms.

And once that Dadabik users usually don't change much of it's structure, anyone who's familiarized with it can make a huge mess.

I'm not telling you to start messing around other people databases, just saying that if you're a user, start thinking on:

a) giving your db user only read access to your database.
b) turning exec/write permitions OFF on admin.php (so that anyone can change it) It would be a nice idea to change those same permitions on internal_table_manager.php as well.

And if you're a developer, start thinking on:

a) implementing security components to Dadabik.
b) tell the user (while on the installation of Dadabik) about security issues.

And that's all I have to say about this subject. :)

I hope I could help you guys out as you help me. Thanks!

Cheers,
Marco Tulio

 
D

Debbie S

Guest
Marco Tulio

How about, as users, everyone start reading the DOCUMENTATION that comes with the package? In the security section of the documentation, it clearly states:

"" Since the files install.php, admin.php and internal_table_manager.php could be used by malicious users in order to change your DaDaBIK configuration, it is a good practice to protect them or to delete them if you don't need to configure DaDaBIK any more. ""

If you don't want to delete these files from your web server and re-post them when you want to make changes, there are a couple of ways you can secure them. You can rename them (just make the necessary changes inside the admin.php and internal_table_manager.php files so they still refer to each other with their new names). You could insert authentication code inside each of these files (there are several scripts on the 'net for this). Bottom line is, there are ways to secure these files -- you have to choose the method that works for you.

As for your comment "giving your db user only read access to your database", you, as the person configuring the DaDaBIK interface, turn on/off permissions for interacting with the DB data through the admin.php and internal_table_manager.php. Through these files, you control what users can and cannot do while viewing your DaDaBIK front-end. Did you read the section on using two instances of DaDaBIK -- one for view only and one for admin of the data? There is also a per user authentication built into the latest version of DaDaBIK if that is what you are after.

I do not believe it is unreasonable to expect that those who choose to implement DaDaBIK will also assume the responsibility of securing their own data and configuration of the program. The methods are available, all you have to do is implement them.

Debbie
(Latest version of DaDaBIK when this message was posted: 3.1 Beta)
 
Top