Page 2 of 2

PostPosted: Wed Feb 14, 2007 2:49 pm
by Wrangler
a) SetVar "[Score]" "{php script commands to erase all files on the server/folder}"


Ok. How would a user of the nb program be able to setvar [score]? The data in the variable [score] would be determined by the program code, presumably in this case by adding up the right and wrong answers to the quiz. The user would not be able to change that data. The php script would only write to the text file what is contained in [score].

Let's say someone with a copy of nb were to write a program to attempt to do this, where they can "setvar". Posting malicious code to the php file would only write that code to the text file on the server, not execute it, right?

PostPosted: Wed Feb 14, 2007 5:00 pm
by Gaev
Wrangler:
Ok. How would a user of the nb program be able to setvar [score]? The data in the variable [score] would be determined by the program code, presumably in this case by adding up the right and wrong answers to the quiz. The user would not be able to change that data. The php script would only write to the text file what is contained in [score].

You are missing the point ...

- NeoBook's InternetPost command is not doing anything proprietary ... the data that arrives at the server/script is EXACTLY the same as if someone typed it into an html form and pressed the Submit button inside Internet Explorer.

- as it stands, the minimalist php script compromises the security of the server ... no matter how the data is generated ... primarily because the script has no checks about the name of the file to be used to store the data ... this information is also being sent with the rest of the data.

- it would be similar to a NeoBook pub with a Call command to an external file ... someone (using notepad.exe) created a script file that did a SaveVariables "mypub.var" command (which would dump the value of every variable's current value) ... or one with commands to erase all files ... etc. etc.
Let's say someone with a copy of nb were to write a program to attempt to do this, where they can "setvar".

As I said before, you don't need NeoBook to send malicious code to a server/script which has no checks ... just some "Sniffer Tools" to examine traffic TO the server/script ... and try and break through with combinations of malicious data/filenames.
Posting malicious code to the php file would only write that code to the text file on the server, not execute it, right?

See item (c) in my last post.


If you think this is not important, note that earlier versions of PHP were susceptible to exactly this kind of problems ... until they introduced the concept of "Register Globals" ... and take a look at any php script that accepts data (POST'ed) from a form ... that includes uploaded files ... and you will see the lengths they go to in order to make sure it does not compromise security of the environment ... usernames, passwords, hidden fields and restricted file names, extensions and target folders (with no execute capability) are all deployed within such php scripts.

PostPosted: Wed Feb 14, 2007 5:23 pm
by Wrangler
Ok. Thanks, Gaev. Now I understand. I think my lack of a thorough understanding of php made it difficult to comprehend. Yes, I think it is important to know about this stuff. This was a good discussion. Valuable information.

PostPosted: Thu Feb 15, 2007 10:48 am
by Neosoft Support
David, thanks for pointing out the potential security flaw in the php script.

It seems like the file name variable is the cause of the security concerns here. Could that be solved by hard coding the file name instead? For example:

Code: Select all
<?
$file=fopen( 'testresults.txt', 'a' );
fputs( $file, "$data \n" );
fclose( $file );
?>


Someone could conceivably write some garbage to the file, but they couldn't execute it.

PostPosted: Thu Feb 15, 2007 12:09 pm
by dpayer
Neosoft Support wrote:David, thanks for pointing out the potential security flaw in the php script.

It seems like the file name variable is the cause of the security concerns here. Could that be solved by hard coding the file name instead? For example:

Code: Select all
<?
$file=fopen( 'testresults.txt', 'a' );
fputs( $file, "$data \n" );
fclose( $file );
?>


Someone could conceivably write some garbage to the file, but they couldn't execute it.


Yes, exactly right.

Still, one has to be careful of who you allow to upload things. I wouldn't want a situation where anyone could upload continuously and have an adverse impact on my server.

What might be best is to include a username/pw routine right in the page and also include the file type. This way only those people (programs) that knew the combination could post to the page.

If this is a linux/php server. I think a simple .htaccess list would work.

David P