Adding index.php

[gmoore]

I added this index.php file to each directory that was appropriate (not the root):

 

<?php
/* Redirect browser */
header("Location: ..");
/* Make sure that code below does not get executed when we redirect. */
exit;
?>

 

(Awesome markup utility !!!!)

It was made to stop prying eyes by pushing them up 1 directory level. Eventually getting to the top.

 

Greg

Edited January 10, 2013 by gmoore

[Someone]

A form of .htaccess failsafe. It would tell potential hackers that there is something in that folder though. Perhaps the header should give 404 instead, just as it would if there was nothing there.

[gmoore]

(Okay what did I do wrong displaying the code lol ... I thought it was explained perfectly to me)

[Someone]

Do not have the . in the brackets. And when using php you can use [.php] instead of [.code], again no dots. If you use the go advanced button,you can mark text, and get the BB code added around it

[sniko]

(Okay what did I do wrong displaying the code lol ... I thought it was explained perfectly to me)

Remove periods (.)

I'd return a 404, too. Hackers usually check the headers that are being passed/thrown

[gmoore]

I have been doing a number of 'custom' things to deter hacking. I have renamed all the subdirectories, changed location of admin modules and made all files php. It's a little work but the problem will be that at some point people find out you are using an engine and they can possibly come here and find flaws to exploit, perhaps before I see them.

I am sure alot of what I did is overkill, but 'I' feel better. My task is only to propogate over changes from the baseline systems as they come in.

Now back to the 'base' NWE system. It's like basic training, beat them down in order to build them back up more powerful :rolleyes:

Greg

[gmoore]

I changed [.CODE] to [ P H P ] and it all disappeared. (And the tail blocks too)

 

Fixed: I didn't quite understand to go to the Advanced button first. ty all.

Edited January 10, 2013 by gmoore

[Someone]

I get why you did it, and yes, if/when it gets popular, they will rip apart the engine to find flaws. Hopefully there none there, but well, pentagon get hacked from to time.

But when you redirect, you tell anyone scanning your site, hey there is something in this folder, apply more scanning for files here

Speaking of security, in my server logs on one of my sites, something that is popular to scan for is tinyMCE (3rd party scripts for improved text areas), apparentyl some versions of tinyMCE has security risks (I have not reason to think this applies to the version that comes with NWE, I have not checked it out yet, just something to be aware of)

Edited January 10, 2013 by Someone

[gmoore]

That's what we need ... a Security Alerts Forum here.

Greg

[Octarine]

A ""Security Alerts"" Forum -- Seriously?

It's utterly pointless. I've pointed out holes in almost every so-called ""engine"" here, yet to this day they are still open to multiple levels of abuse. Why? In part because the authors don't understand the problem itself which is fair enough, and in part because they are too lazy to do the work themselves.

Look at McCodes. Insecure to this day because the owner(s) are lazy. Pointing out a problem to them earns no credit at all, and even when the identical problem manifests itself in multiple files - pointing out the problem in one file means they fix *that* problem, nothing else. (And even that can be taken under advisement - I can refer you to multiple instances here quite easily.).

NWE; well that's an odd one. There are some interesting albeit obscure holes in it (at least as far as this forum is concerned). Alain has either ignored or simply been unaware of some of the basic injection points - though to be fair, I know most if of the problems *have* been secured, in one way or another but initially, there were some questions.

EzRPG, lovely gaping holes quite simply ignored by the current author(s) as apparently, they think they know what they are doing. Okay, fair enough, we are all perhaps a little over protective of our code, but really, in this case, any half descent testing would find the problem pretty much instantly.

The remainder of the less popular engines - well, 'nuff said. They have all sorts of interesting problems, some of which I've pointed out either directly to the authors or in whatever active forums I've found yet little if anything has been done to address the problems.

The answer? Sorry, I can't help you there. "Understand the problem before you ask the question" is probably the best I can come up with, but it's hardly helpful. Security is dreadfully simply when you understand the model you are working with; but so few people seem to be capable of accepting that it is actually outside of their area of understanding. It's actually not that a difficult task to find a hole, it is however a different matter to explain it in terms that can be easily applied to any web application.

Advice? I have none - Understanding how insecure data is stored, and then displayed is probably a key trick to learn however and is almost language and database agnostic. Data In -> Escaped -> Database -> Escaped -> HTML rendered. Yet therein lies a hole can of worms, not least of which is encoding and the rather more entertaining database escaping.

As for the big guns, the Pentagon etc. Consider the problem. NWE/McCodes/EzRGP - a PHP game running probably under Apache on hopefully a baby Linux system .... versus a (theoretically) military grade system running .. well lets say UNIX to keep things simple. Game ..//.. Military. Really, you don't need that strong security, you simply need the sufficient to protect you, your server and your users.

Address the problem from a different angle. Think about the level of control / security you need in respect of the time it takes to recover from backup, repair a lost table etc, repay a lost $3 etc versus spending the next several years working out the next best thing in (for example) password security .. which BTW is *not* PBKDF2 password. (And for those of you still paying attention, scoobie snacks will be award if you can tell me *why*).

[Someone]

You faithfully pop up whenever there is security talk I see.

So I should not spend any time, checking of the version of tinyMCE that comes with NWE is secure, because it will be faster to restore a backup.

I see it as I am having a responsibility of the data entrusted me by my sites users. And I secure my server as good as I can to my knowledge.

 

NWE; well that's an odd one. There are some interesting albeit obscure holes in it (at least as far as this forum is concerned). Alain has either ignored or simply been unaware of some of the basic injection points - though to be fair, I know most if of the problems *have* been secured, in one way or another but initially, there were some questions.

Point them out, and I will fill them on _my_version of the engine, and share the updates with others in this community.

So much text, and yet you offer no advice.

[gmoore]

I worked for the 'US' department of defense for 12 years (web development). Some in Europe, some here in the states. I had to take training that makes me want to hide under a rock. I mean this is a game system ... I am not trying to protect from the 'real' bad guys BUT I want to be smarter than joe average hacker. In the month I have worked with NWE, I have found a responsiveness to the code I have NEVER seen before. We (and I hope I can be considered part of this community), We communicate, critique, fix and help each other. I am very happy with what I have seen.

So, it's a game, I work with backups as my last resort, I just don't want to make it easy. If we make a million, we can change things to be 110% secure. Even our banking sites puke over anyone even thinking they will be breached.

Please post the holes you have found, since I will be one of the first to help correct them. Well unless Alain or the others beat me to it. 1331 has to be sick that day so I have a chance :cool:

Greg

Edited January 10, 2013 by gmoore

[Someone]

Exactly, like a car alarm. It does not stop people from stealing your car. But the average car thief will rather steal the one parked around the corner without one.

[a_bertrand]

I doubt I ever ignored on purpose any security hole, whatever was reported as security issue (like the NPC discussion) has been addressed. Maybe on some form, that's due to my own twisted way to solve things, but yet I hope to follow any feedback I ever had. The only thing which I didn't addressed yet and I remember you reported to me Octarine is the need of unit testing. Something else I forget?

For the index.php file on each directory, honestly I doubt it adds much security as well as I doubt changing all files in php does and good. Why? First of all the .htaccess should prevent to browse the files, second the modules files called directly do... nothing as they lack all the lib files. So I hardly see adding an index.php file being a strong security. Anyhow feel free to do it the way you want, it's your installation anyhow ;)

I don't like much the security by hiding, I think it gives a false protection feeling, where if you design the things to be safe and yet visible to all it should actually be better. Again my feeling.

[Djkanna]

I changed [.CODE] to [ P H P ] and it all disappeared. (And the tail blocks too)

Fixed: I didn't quite understand to go to the Advanced button first. ty all.

Using PHP tags, in quick reply, won't show up straight away (there's no refresh, for the client side highlighter to do it's magic) - refresh and it'll be there, don't worry. :)

[gmoore]

So its just a delay thing. I thought I was following your example. But I got it now. ty

[sniko]

[...]

Address the problem from a different angle. Think about the level of control / security you need in respect of the time it takes to recover from backup, repair a lost table etc, repay a lost $3 etc versus spending the next several years working out the next best thing in (for example) password security .. which BTW is *not* PBKDF2 password. (And for those of you still paying attention, scoobie snacks will be award if you can tell me *why*).

I'd love a scoobie snack!

From researching, I've gathered the following; please inform me if I am incorrect.

• PBKDF2 is a password-strengthening algorithm, but vulnerable a rainbow (Like anything else, if you have the key.)
  
• As PBKDF2 is a password-strengthening algorithm, there are different cryptographic hashes, SHA1, for example. People may use outdated cryptographic hashes.
  
• With enough power (computing) you can crack the encryption (According that enough iterations are performed)
  

 

Now for some direct quotes

It is actually faster than bcrypt (see Colin's paper); in other words, even without waiting for a hypothetical research result against bcrypt, PBKDF2 is already "vulnerable".

Or am I too far down lar lar land?