[tcaudilllg]

I'm ready to release Iconsole, but what security do I need? Should I implement security myself, or allow the user that responsibility?

I've determined not to create a login panel, leaving that to the user's discretion. I may make one later, but it will be only an add-on, not a selling point.

Is there any real risk that I am running producing this product, that it could open up an already secure server to attack? Thanks in advance.

[RuneLancer]

Well, I guess I can't be a jerk to LG EVERY post he makes...

The simplest and most often overlooked security holes in a program come when the user can enter data one way or another and that data isn't tightly monitored. For instance, at work, we once had a program that allowed the user to enter footnotes in a document through the browser. These footnotes would show up in a div. One of the problems with these were that, the page being html, the user could've done something like this...

La la my footnote goes here.</div><div class="SomeClassTheDocumentUses">New text! Gasp! The user can now modify content without us knowing!

Since the footnote was inserted between two div tags, the page was fooled into thinking a new paragraph had been added in the source document when it would display the footnote. Seeing as this was for a law-related thing, the conscequences could've been pretty nasty. ;)

This is especially dangerous with, say, a search engine that inserts the user's query in a SELECT statement directly. Can you say "DROP db_name"? :)

Another common security hole is when posting sensitive data through a get instead of post. Since it shows up in the address bar, other users can easily steal passwords this way, or worse, submit data they shouldn't be allowed to submit. (such as changing "...&userlevel=3.." to "...&userlevel=1.." Of course, if anyone's dumb enough to handle access levels like this, they almost deserve a good hacking. :o )

These are the most basics ones, and they're very easy to fix.
_________________
Endless Saga
An OpenGL RPG in the making. Now with new hosting!

[tcaudilllg]

Thanks for the help. :)

I'm going to leave it to the user not to try to break the JS/HTML. If they really push the limits, they'll have to reload the page.

What I'm concerned about is the filesave function. It uses PHP and saves the file directly by writing it to disk. I'm thinking that read/write permissions (which I can leave to the user) will be enough to curb mischeif here. But I'm not sure. In particular, I know UNIX offers all sorts of esoteric commands, and most of the users will probably be hosting their iconsoles on their website. (that's what I've intended in the design)

Is there anything out there that can totally screw me (and users) at the UNIX end? Or will file permissions cover enough bases that I need not be kept awake at night?

[LeoDraco]

Like the proverbial spoon, there really is no guaranteed security; the best you can ever hope for is, simply, to make the resource you are protecting difficult to access. Given enough time, money, resources, cleverness, porn, etc., the determined cracker could pretty much get into anything. (Which is not to say that you cannot have "security": like the proverbial time/space tradeoff, a "security"/"flexibility" tradeoff also exists; as you move a system towards a more "secure" state (i.e. harder to break/crack), you tend to loose flexibility.)

Having a "I don't really care about security, even though I am asking about it" attitude about things certainly will not help matters, either.

In any case, while the following thread has to do, mostly, with logins, it should still prove an informative read for increasing the difficulty of cracking. (Really Galbalan: ever try looking through the fora prior to asking questions?)
_________________
"...LeoDraco is a pompus git..." -- Mandrake

[DrunkenCoder]

Well basicly what they said.
The most important thing to secure is the gateway where user data enters the system. Code injection (as pointed out by RL) can be very severe also having a file-upload feature espically one that's open to public consumption can easily backfire.

Just see to it that quatoas are used or you'll be in DOS hell.
_________________
If there's life after death there is no death, if there's no death we never live. | ENTP

[Nephilim]

Are you talking about file permissions for other users on the same web server, or from remote client access via the web server? If the former, yeah, make sure you set your file permissions so that other users can't get to your stuff. But for remote access, permissions are relative to the user PHP is running as, not your remote user.

Be sure to validate the format of the file to ensure that instead of a map file, it isn't writing, say, a PHP page that can then be activated to drop all tables. The XML validation stuff is probably the easiest way to do this, but you could roll your own for some custom format. Another trick is to obscure where the file is actually stored by using PHP to act as an intermediary. This way, the data is (hopefully) only used in the context of your web app, and not called directly by the client. For instance, you could store the data is a safe place outside your document root, preventing anyone from requesting the file directly. (Just be sure that you compute the path on your end, so that people cannot bust out of that directory and access files on the server willy-nilly.)

You might also consider using something like mySQL to store the data instead of files. Then you can be pretty certain that you're not letting users inject unwanted files onto your drive - it's all wrapped up in database data. And you get all the added benefits of storing searchable metadata alongside the actual content - if you have multiple users, you're probably going to want this sort of functionality anyway, so you might as well store it relative to user data.
_________________
Visit the Sacraments web site to play the game and read articles about its development.

[tcaudilllg]

Quotas are good. Yes definitely. I could read the file size quota from an external file. I could also read the target directory from a file, too, allowing the user the responsibility of setting up their own folder heiarchy. Very useful.

Good ideas, all of you. Thanks a lot.

[Ren]

Like someone already said, the most important thing to protect yourself against is SQL injection, because every man and his dog knows how to do it. File quotas are pretty useful too, after all you don't want some git from flooding your server. Theres no real need to read it from an external file though because unix OS's handle file quotas just fine. That said, I don't know if PHP can tell what the file quota actually is, it'd just give you a write error when it gets full.

Of course the most useful thing I could suggest is creating regular back-ups, because total prevention is pretty hard. Although this is really down to the end user, unless you want to program your iconsole thing to create regular dated backups somehow.

Did we ever find out what iconsole was for?
_________________
Previous nicks: MidnightDreamer, The_Anarchist, Shroomasta.

ren-tek.net : BGC games and more!

[tcaudilllg]

Iconsole is for... just about anything you can think of having to do with organizing data.

For example, you could have a set of icons set aside for MIDI program changes. You could have icons with text corresponding to guitar settings for say, the distortion guitar, bank 3, volume 32, and I can't remember what else right off hand, because I'm not very much into MIDI right now, but you get the picture. You can associate data patterns with icons, and just point and click to add those patterns to the stream of a larger pattern, and then save that pattern. One could imagine icons as postulates that have each been demonstrated as useful for a given purpose, and meant as the basis upon which to conceive more complex concepts.

Say for example, you had a list of icons set aside for math functions. You could set the data of each icon as say, a formula in calculus, and then arrange those formulae in the order you wanted to arrange them in to create a larger formula, by clicking on the icons that correspond to the formulae. Then you can save that stream of icons as an icon in its own right, with its text corresponding to the new formula.

In summary, icon-based thought is the concept of associating patterns with pictures, and recalling the pictures as a means of building their corresponding patterns into newer, bigger, patterns.

[bay]

[Ren]

[Adam]

[DeveloperX]

[tcaudilllg]

I hadn't expected you to. I'm confident I can handle it myself, thanks.

[tcaudilllg]

I made those changes. Files "quota" and "path" are referenced before saving, if they exist.

I've been considering implementing a basic version of SQL... not for this version of Iconsole, but for later. (there may be an Iconsole 2, or there may just be a free upgrade...) Is there need of a public domain low-powered SQL processor?

EDIT: nevermind. SQL has been almost completely fused with XML. That's simply too much work for too little. But I think an implementation of one of the earlier standards may work... still looking it up.

Another EDIT:
...What I was thinking, is a way to have someone register for say, a message forum, and in so doing register for a whole bunch of things besides. It seems that SQL would be the best way to do this, because SQL is the dominant database query language, no?