Question: About open files

[gmoore]

Does anyone have an interest if I post some changes to get rid of a users ability to spy on the system. Specifically, XML files and SQL files? My feeling is people will know the site uses XYZ system. Thus, they can figure out that modules/somethingmodule/config.xml will tell them things probably not public about the system. Likewise, en.xml under the language directory (I know .htaccess is there, but what if I stupidly erase it) might gain insight into the game illegally. Or perhaps install.sql under modules/combat might show all my nice happy statistics and work?

So I have been putting all these files into .php files as variables to be loaded by the core. Are you interested or do you think I am paranoid? I don't believe in htaccess files is all. DTA, don't trust anything :)

Greg

[gmoore]

Also, my goal is to record attempt at access these types of files, record it and possibly ban the IP in order to track hackers. And I AM paranoid.

[Someone]

As for developing this kind of sites, you are not being paranoid. You will get kids trying to cheat and hack your game. These games are hackors galore

On the live version of the game, I will not have anything related to installation of modules. I will simply delete sql files, a user cant see live stats from them, but they can see the structure of the database, pretty helpful if you want to hack something.

Been thinking about .htaccess nice that they are there, but apache reads them for every sub folder that it encounters one. A bit of a performance chocker. I will use one, but only in the root modules folder, that will deny all but png/js. I do wish there was a core standard that these files was not at the module locations.

Vital files are best kept outside of the public folders. Like on cpanel based servers, kept outside of public_html and then included in. I have never actually done this, but know its possible.

Apache does log forbidden access requests. On a site I got attacked, I logged all post/get data sent to all pages, that table got stuffed to the millions pretty quick (did not know much about mysql back then, table was indexed by username aka varchar), something like that could be handy to activate on suspect users though.

[gmoore]

Well I have used CodeIgniter on many sites I have done. You can place everything but css/js/images outside of public directories by default. This way the only access users have is through controllers. You can also make nice URL's rather than these old fashioned kinds. Choosing where to start has been my problem in developing games recently:

1) Codeigniter from scratch: I know its mine, I know it inside and out, designed the way I like it (every programmer is different in their likes and dislikes which is no fault of NWE) .

2) Use a CMS like Wordpress/Joomla/etc: Good solid system but usually a BEAR to change or add to.

3) Use NWE: Which is like 40-50% of a core system I can use.

4) And new to me now, NWE redone in CodeIgniter: Lots of work and is it feasible because I wanted something running in the first place to save me time which would put me back at #1.

I keep starting and stopping over the last 8 years.

Greg

Edited January 3, 2013 by gmoore

[Someone]

Codeigniter + NWE seems like a good solution for your project then. For now I am sticking with keeping NWE as is in its core, at least while developing the functionality of the game features.

[gmoore]

But Is start AGAIN where I was BEFORE. I want to love this new system but I keep seeing things that are (don't want to say it) half done or just started but not finished. I know I didn't buy Word or Excel with over 1000 programmers working on it, but I HOPED for something more fine tuned.

Greg

[Someone]

I think you need to just get started making your game!

The surrounding stuff, is rather minor to change after the game is done. No disrespect, but your concerns seems to handicap you from getting your dream game made.

[sniko]

I think you need to just get started making your game!

The surrounding stuff, is rather minor to change after the game is done. No disrespect, but your concerns seems to handicap you from getting your dream game made.

Perfection is the enemy of progress

[gmoore]

So perfectly put. I am a perfectionist. My wife just laughed, she said 'they have you nailed' lol

[sniko]

So perfectly put. I am a perfectionist. My wife just laughed, she said 'they have you nailed' lol

Ahaha, gmoore, that is pretty funny!

[Someone]

LOL

Sounds like a sensible wife

[gmoore]

But maybe my custom code is a better idea even if I paid for this source code :(

[Someone]

It would still be of _some_ value. You save some hours, by just ripping code from it and use in your custom version. Even if its just 10 hours, thats 10$ an hour, for sure your time is worth more than that. For me, just session management or template system would take 10 hours.

[a_bertrand]

I doubt the 100$ you invested in NWE is of no value ;-) Anyhow you could have started with the free version and saw how it was done.

Anyhow back to your point, I think most of the files are actually blocked via .htaccess already, if it's not the case please give me the info and I shall check. Also, NWE is not yet a dead product in the sense there is no more development on it, so if you have suggestions, please share them and we shall see what we can do.

[gmoore]

Oh I know. I appreciate the work you have put into it. I have been weighing how much I need to customize before the game can go ahead.

I appreciate the work you put in helping us! (Can you tell we were busy while you gone?)

Greg

Edited January 4, 2013 by gmoore

[john-doe]

I doubt the 100$ you invested in NWE is of no value ;-) Anyhow you could have started with the free version and saw how it was done.

Anyhow back to your point, I think most of the files are actually blocked via .htaccess already, if it's not the case please give me the info and I shall check. Also, NWE is not yet a dead product in the sense there is no more development on it, so if you have suggestions, please share them and we shall see what we can do.

If you are using the Front Controller pattern (A centralized entry point for handling requests) you should be able to move all application and core files outside the root and just keep the public files (css, javascript, images) and the index.php file there.

Another suggestion would be to define a constant which handles if the user is allowed to direct access the specific file.

[a_bertrand]

john-doe: it's like that already, you don't access PHP files beside the main one directly. And everything should be blocked at the modules level due to the .htaccess file there which deny everything. So unless I didn't saw something or your hosting doesn't allow .htaccess files, you should not have any issues.

[Octarine]

Also, my goal is to record attempt at access these types of files, record it and possibly ban the IP in order to track hackers. And I AM paranoid.

Really there is no point in bothering to ban IP's, it's futile. Just looking at the intrusion attempts in the last week on a box I manage - around 320 IP's were flagged as doing something unusual; but is there any need to block them? No - Sure, the few that present a concerted attack on the server - say several thousand attempts per minute were simply firewall'd out - but that should *never* happen at the application level - it's best left to pretty low level stuff. The rest, you can simply ignore. That's assuming you are not one of the usual types here who blindly put up public facing scripts with more holes than a slab of swiss cheese.

If you use a decent front end system, then it's own logs can be used to determine intrusion by writing a few short scripts that will perform far better than anything you can dream of at PHP level. In fact, the last thing you ever want is Apache/PHP dealing with anything *but* the application itself, as NWE has some interesting design issues that render it .. shall we say "not optimal" .. for production use.

The other benefit to looking at raw server logs is that it becomes an application agnostic solution, something that should be considered strongly in its favor. Look at, for instance: denyhosts. A half decent solution to a particular problem. If you can write something that looks at all requests to a server (note - server, not service), and sensibly block them, then you have the makings of a very decent tool - but, there are some extremely good ones out there already. SourceForge/GitHub - both good places to have a look.

There are tools semi built-in to Apache itself, that provide decent logging facilities. There are also some very good tools for looking at Apache's logs, though really, sitting down with Perl for 10 minutes or so is enough to rustle up a script that will flag unusual activity in most log files.

You could use an application level IDS but again why bother? Assuming Alain has not gone the remarkably popular route of carelessly leaving huge holes for XSS/SQL - both of which can instantly be considered a game-over event - then is there any need to log/trace/penalize users for making an attempt?

If people type in ``<script>alert(1)</script>`` or ``" OR 1 OR login_name="yada`` into a field - possibly some form of mail to another user or a login form, is there any need to penalize them? No of course not. By ensuring you escape the data correctly, they will simply be unable to affect the server in any way other than that which was intended. Yes I agree, there is a case for the "but what happens if somebody discovers a bug in my code or PHP itself" route. Well in your code, that's your own fault. If you can't test it properly before releasing it - or realize that it's wise to have the code checked over then so be it. With a fault at PHP level (or lower god forbid), then yes, logs are handy, but more important is ensuring that your application is well sandboxed from others on the same box, and that you have some form of sane backup and recovery solution.

tl;dr:

Don't use the application itself to discover, track, log and possibly penalize users for attempting to breach whatever defences you have.

[john-doe]

john-doe: it's like that already, you don't access PHP files beside the main one directly. And everything should be blocked at the modules level due to the .htaccess file there which deny everything. So unless I didn't saw something or your hosting doesn't allow .htaccess files, you should not have any issues.

I see. Anyway, "everything should be blocked" but what if your hosting doesn't allow mod_rewrite? What If you accidentally break the .htaccess files, now we do have a problem.

For best security it's wise to place application and core files above the web root so they can't be directly accessible via a browser.

[Someone]

For best security it's wise to place application and core files above the web root so they can't be directly accessible via a browser

That I believe this to be true. On the other hand, if a host does not allow .htaccess or mod_rewrite, there is no chance in h*** they will allow you to run a browser game on that account. Hosts such as hostgator will suspend your account even with very little activity, its even their TOS not to run browser games.

You can set Apache to only use one .htaccess file that is in the root, and not look for it in all sub folders. But hard for the engine itself to account for every type of system setup. I think that in the end these matters are up to each game owner.

[gmoore]

hostgator doesn't run browser games? please link that up here or I might as well jump off a cliff :)