Tuesday, February 1, 2011

Why it doesn't pay to stint on I/T

To respect security, I won't be mentioning names. But earlier this week, I was trying to access a large-ish website that was clearly buckling under the crush of traffic. After plinking the F5 (i.e. "Refresh") key a few times, I left the web page open as something else claimed my attention

A minute or three later, I noticed my browser's "Download" notification window asking me whether I wanted to download a PHP file and open it in the application designated for that file extension. At that point, strict professional courtesy should have made me say "no," but I rationalized that I would do no tangible harm by just peeking.

Now, if you're not a web programmer, what you need to know about how most web content is served is that it often involves some delegation. What's traditionally known as a "web server," is capable of handing off files (HTML and images and such) that don't change. When, however, the content is updated in real-time (which is to say most of the web nowadays), the task of generating it is left to another software package, sometimes known as an "engine" (e.g. servlet engine, Zend engine). The engine's output is then handed back to the "web server" as HTML and images and such and delivered back to the user's browser.

That's how it's supposed to work, anyway. In the case of the website I tried to access, the "engine" portion had clearly stalled out under the traffic load. The web server, still struggling to keep up with the requests for content, finally sent the PHP files responsible for delivering the content--or at least one of them.

That's bad. Why? Because, exposing the code files themselves exposes the inner workings of the web application. That could include information about the database structure behind it, and--in an Armageddon-worst-case-scenario--the connection information for the database itself.

In all fairness, and for perspective, that scenario would involve the proverbial perfect storm of a web server near-meltdown, sloppy programmers, and even more slovenly system/security administrators to set up that sort of situation (plus make it easy to exploit). But it's also an excellent argument for not automatically defaulting to the least expensive, get-ya-by-for-now option. In hardware or people, by the bye. Simply because there's being caught in out the perfect storm, and then there's doing the rain-dance for it. Moral of the story: Don't be that person.