Sean Nichols (mrputter) wrote,
Sean Nichols
mrputter

  • Location:
  • Mood:
  • Music:

Somewhere in Cleveland there's some guy named Al Kida (K-I-D-A) -- he's Freakin' Out

So there's nothing quite like the sudden realization that code you've written (and which has been live for a couple weeks) is about as secure as a sieve.

Specifically, code which handles and validates course assignment submissions.

Oh, I took care of all the micro issues, like worrying about SQL injections, sending plaintext passwords over the wire, buffer overflows, malicious filenames and all yer standard stuff. But as we shall see, this amounted to but a thin cotton cloth lining the metaphorical sieve.

Now in my defense, it wasn't entirely my fault—rather it had more to do with the dumbass way they set up the webserver in our department. But be that as it may...


The CPSC department used to have a most excellent, well-tested and well-secured assignment submission system that served for many years. Until last year, when for various reasons (read: department politics) it was taken down. So I decided to write my own webform for the purpose, which I duly put on the course website.

In retrospect, PHP was perhaps not the ideal choice of platform. In an appropriately-designed environment, sure, it would have been just splendid. But ours hardly meets that criterion.

All seemed well until this evening, when I had a request from a student to give him an extension on the upcoming assignment for what was an eminently reasonable rationale. I therefore happily acquiesced, and went to grant him an extended deadline in the submission system. When it suddenly struck me that the database containing the due-dates was actually accessable by anyone on the system.

Which would not have been an issue, save that the path to the file containing my password for the database (even if only the one granting read-only access) was hard-coded into the PHP script.

Which would not have been an issue, save that the PHP script (and the abovementioned file) had their read flags set for the "apache" account, necessary of course for Apache to be able to read and execute them.

Which would not have been an issue, save that every single CPSC student is able to set up a PHP (or otherwise) script on their account, which is run on Apache, and can therefore read any file on the system which has read-access granted to Apache.

Which would not have been an issue, save that the database ALSO contained the path to the directory where I was saving the files which had been submitted.

Which would not have been an issue, save that Apache has write access to that directory (how else can it save the files there?). So in other words, with but a few minutes' applied brainpower, any student in the class has arbitrary write access to the directory where the submitted assignments are stored.

Which is a teensy-weensy tiny little issue.


So in a panic I took the script down (This channel is experiencing technical difficulties. Please stand by.) and have spent the last 7 hours hastily re-writing everything in C. Why C? Because I could then compile it to an a.out binary, for which Apache only requires the execute bit set, not the read bit. And which is therefore marginally more secure against prying eyes. (Oh yes, I also changed the database password, and the directory where everything is saved.)

I'm still worried, though. The submission form is back up, but for how long? How many other obvious blunders have I missed? Even though the submission handling code is now ---------x (and cannot therefore be run through strings), I'm still uneasy about how everything is put together.

Simply re-writing in C feels like an awful horrible kludge. The saved-assignments directory, for example, is still Apache-writable, even if its path is now better-obscured.

But what else can I do?


What obvious security principle am I missing?



Dryer Cat is not amused.
Dryer Cat is not amused.
Tags: angry cat, programming, school, server, teaching, work
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 3 comments