Author Topic: File I/O - abusable?  (Read 844 times)

I'm working on my first script ( a modification of this ) and I need to store large amounts of information (let's say a 1000 char string). I don't know how to do that with ordinary brick events, as the char limit is around 200. However, I've found that using file I/O is very easy and convenient. The user enters the directory of the file they want to access, and the script then converts the file into a series of notes that are played in Blockland. Quite easy stuff, in other words.

But I'm wondering if giving access to my computer like that is abusable somehow. Can the user hack his way into my computer by sending some stuff along with the packets that request access to my file?
The code looks like this:
Code: [Select]
function fxDtsBrick::pianoSynthRFF(%brick,%nameOfFile,%delay,%client)
{
//blabla
%brick.noteCount = 0;
%brick.isPlaying = 1;

%file = new fileObject();
%file.openForRead(%nameOfFile);
playSynth(%brick,%file.readLine(),%delay);
%file.close();
%file.delete();
}
Is this method safe? Or do you suggest anything else?

To my knowledge there is nothing that the user could do other than pick which file in the Blockland folder they want to openForRead.

The user cannot access files both abovee the blockland directory, nor those dieectly in it. It must be in a subdirectory if the blockland directory to be accessable. For example -
Key.dat - no
Blockland.exe - no
C:/some/stupid/thing.txt - no
Blockland/config/server/server.cs - yes


Assuming the files are only open for read and are never written, you'll be fine.
Assuming the files are open for write at some point and they are never exec()'d, you'll be fine.

The only flaw i can think of is that the client could theoretically reconstruct files on their end by observing the sounds that are played, but that would be both highly sophisticated and awesome.

I woukd suggest creating a "music" directory and forcing the clients to stay in there so they don't hear the synth for super secret code files.
« Last Edit: April 15, 2013, 10:30:45 AM by Lugnut »

The only thing you should worry about is if you let users write files. Make sure to isolate where they can write to a separate folder and make a size usage limit per BL_ID.

The user cannot access files both abovee the blockland directory, nor those dieectly in it. It must be in a subdirectory if the blockland directory to be accessable. For example -
Key.dat - no
Blockland.exe - no
C:/some/stupid/thing.txt - no
Blockland/config/server/server.cs - yes


Assuming the files are only open for read and are never written, you'll be fine.
Assuming the files are open for write at some point and they are never exec()'d, you'll be fine.

The only flaw i can think of is that the client could theoretically reconstruct files on their end by observing the sounds that are played, but that would be both highly sophisticated and awesome.

I woukd suggest creating a "music" directory and forcing the clients to stay in there so they don't hear the synth for super secret code files.

Ahh! I see.
I'm not too afraid about reconstruction of files, so that doesn't concern me.  

The only thing you should worry about is if you let users write files. Make sure to isolate where they can write to a separate folder and make a size usage limit per BL_ID.
Of course. I haven't made the write part yet, but I keep that in mind.
On a related note: why isn't there support for reg.ex. in TS? That would've made my life so much easier. String search and replace isn't the best with the default functions. Not enough wildcards!

Ahh! I see.
I'm not too afraid about reconstruction of files, so that doesn't concern me. 
Of course. I haven't made the write part yet, but I keep that in mind.
On a related note: why isn't there support for reg.ex. in TS? That would've made my life so much easier. String search and replace isn't the best with the default functions. Not enough wildcards!
guess what - you can't have the nul byte in strings thanks to torque either. It sucks as a language.

Just make it write and read only files from config/server/musicwrites or something and youre fine
And add a size cap and timeout for reading/writing
« Last Edit: April 15, 2013, 12:31:26 PM by Zeblote »

Just make it write and read only files from config/server/musicwrites or something and youre fine

With writing, you should always add rate limits and size limits though. You can write 50 GB in minutes on a server with no Duplicator /savedup time limit.

The user cannot access files both abovee the blockland directory, nor those dieectly in it. It must be in a subdirectory if the blockland directory to be accessable. For example -
Key.dat - no
Blockland.exe - no
Blockland/config/server/server.cs - yes
Clarification: scripts can only access anything in the default folders that come with Blockland - config, base, Add-ons, saves, screenshots, and perhaps shaders

Clarification: scripts can only access anything in the default folders that come with Blockland - config, base, Add-ons, saves, screenshots, and perhaps shaders

I'm pretty sure you can bypass that limitation with setModPaths.