Author Topic: .conf, security risk? (Read 3470 times)

hobbes · « **on:** March 25, 2007, 02:20:09 pm »

Hi!

I'm no programmer, but it would seem that Bot.conf/Mysql.conf is a potential security risk for people who run the bot on their webspace.

By default, the bot is accessible through the Web in these cases (and some of the posts in the help forum seem to show that some people actually use a web browser to start the bot!), and since .conf is not a recognized PHP extension, it will display as text, showing your AO login info and MySql info.

Maybe I just don't get it, but I seem to remember from the little PHP I learned in school that you always use the .php extension to avoid this problem.

Cheers,
H

Alreadythere · « **Reply #1 on:** March 25, 2007, 02:23:18 pm »

1) That may be a potential security risk, true. But

2) The bot shouldn't be run anywhere where it's accessible from outside anyways IMO.

hobbes · « **Reply #2 on:** March 25, 2007, 03:16:24 pm »

Hell no, it shouldn't! But it would be an extremely easy fix, and I did see people in the support forum post code that showed they did run it in their webspace

Blueeagle · « **Reply #3 on:** March 25, 2007, 04:22:34 pm »

It is my opinion that, if you intend to run this bot in an area publicly availible, you should protect the directory with .htaccess or other access limitation provided by the service that makes it publicly availible in the first place.

Glarawyn · « **Reply #4 on:** March 26, 2007, 06:03:33 am »

It's not a problem as long as you run the bot as intended.

Well, that's not totally true. But the security risks are known.

Besides, anyone who has php sockets enabled on their web server has bigger security issues than a .conf file with their AO or MySQL username/password in public web space.

Khalem · « **Reply #5 on:** April 07, 2007, 03:58:09 pm »

I don't really see why we should fix this as it's not really our problem.

If someone chooses to be stupid enough to run it this way (which by the way usually means your violating the AUP of your provider) and not secure it, they really deserve all they have coming for them.

Imho, a better fix would be for the bot to start checking (if possible) if it's being called through a web browser and die() along with a clear warning in the documentation, even though nowhere is the approach to run using a webserver documented in any examples.

Vhab · « **Reply #6 on:** April 07, 2007, 10:22:14 pm »

I like the latter idea.
Could be as easy as checking for certain $_SERVER vars being set.
Imo implement it and prevent people from abusing a web server as bot host.