attn: thewronghands et al. - Security advice solicited

[digitaldiscipline]

We're trying to implement a fairly basic widget here for supervisors to be able to submit one-shot text data via a web-based form (password req'd - minimally secure, but adequate for tracking purposes in case of evil) that will subsequently be rendered by Flash (actionscript) calling on an xml file.

the initial solution was to have an on/off pointer in the xml to an external .txt file where the submitted text would be written-to. The security-through-obscurity approach took about three minutes to be subverted by our trained management monkey (which is why we asked him to try and break it). hence, this request.

this is far from mission-critical, but we don't want it to be easily circumvented and abused by bored phone drones. do you have any suggestions as far as submitting form data to a secure-enough file for rendering, while still allowing the text file to be modified by the submission form (and, presumably, those of us who wrote it)?

[yes, i'm finally learning to code, albeit tentatively]

Comments

[hellsop.livejournal.com]

Session cookies that expire fairly quickly, or accept the ID and password at the same time as the submission. For little stuff, I much prefer the latter as there's nothing hanging around to usurp. And it's WAY easier to implement.

[etcet.livejournal.com]

the submission of the data is secure-enough (because it uses your second option, and logs it), it's the output file (which has to persist) that's compromised and needs fixing.

[hellsop.livejournal.com]

OS permissions. Only the webserver process shall write to this file.

[etcet.livejournal.com]

this would be a great solution if we had the power to implement it, but we're badly hamstrung by an IT permission lockdown, complicated by corporate policy applications with a penchant for resetting file permissions each time they're executed.

gahh. the solution is simple, obvious, and on the other side of a really big ravine.

ask me about the fun we've been having trying to get sql reports to run sometime. or, better yet, think about asking it, then buy me a long island iced tea and forget it. *facepalm*

[hellsop.livejournal.com]

Welcome to IT. Here's your cattle prod and your bottle of lube.

In this case, where you can't implement the right solution, document
the exposure, document the right solution, and get someone to sign off
that the exposure is acceptable. I got IBM using a server-based PGP
with just such a note: $15k per year for server-based PGP or cheap
licenses on laptops with confidential datasets being downloaded to those
easily-stolen laptops unencrypted. A company policy suddenly didn't matter
anymore in less than a week.

[etcet.livejournal.com]

that's a big cattle prod. i may have a slightly-frayed rubber band by comparison.

this is a trivial tip of the day submission widget, and the only disincentive to spur security being the potential for bored phone drones to put DRINK PEPSI! or PH34R MY SQUIRRELY WRATH or something into the priority tip queue while those of us who have the power to smite the bad bits are getting drunk on a boat (for example).

[jruske.livejournal.com]

I'm confused... before you start writing code I suggest writing requirements clearly. Maybe you can hire someone we know in the midwest (who can also code).

If I understand what you are asking, you want to have a form that takes user input (after a login). The text string captured by the form you are proposing to write to an XML file. The XML file contents are rendered by a Flash actionscript.

Here's an idea... pick it apart and take the pieces you like if it helps.

1) You best be scrubbing whatever comes in on the form. XML is not friendly to tagged material (even accidentally) being shoved into the middle of things. Never mind your code for dealing with all those special characters users love like '.

2) You're web application should be writing the form input out to a file (correctly appending or creating the file if it is not there). Add a user/date time stemp hash into the head of each recorded input.

3) Write a job/demon/batch that renames the input file (preventing locking as the input web app will just create a new file), and processes the input to the XML file. Preferably in a seperate directory not exposed by the web root.

4) Implement your Flash viewer of the XML with a config file that indicates the path of the final XML file. Do *not* expose the path in the Flash, but rather expose the reference to a web server variable that cannot be exported.

Or you could just punish people who hack the XML. I think punishment usually works best and it is definitely cheaper.

[ivy]

I am not a (good) Web hacker. May I point my friends list at this? There are many more skilled than I who would probably be able to give you a way more informed answer. I know jack about Flash and jack about XML, pretty much.