You should not use HTTP request parameters as filenamesOne corollary of the danger of over-powerful introspection is that you should not use HTTP request parameters directly as filenames for any reason, not just to avoid hard-coding allowed commands in your web application. Any time that you use a request parameter as a filename, you create an opportunity for an attacker to escape from whatever directory your application is supposed to get its files from and thus to rummage all over your system. (In fact, you should not directly use the URL for a filename either,
because someday an attacker may feed you a HTTP request for a URL
with embedded It pretty much doesn't matter exactly what you're doing with the file; an attacker can probably find some way of exploiting whatever you're doing. (If nothing else, there are usually files that cause undesirable side effects when opened or read from, including blocking your application. Are you prepared to deal with an endless stream of random data, for example?) The reasonably cautious way to deal with this is to carefully validate
the request parameter to reject bad things like The really cautious approach is to work the other way. Instead of ultimately validating the request parameter by trying to open a filename based on it, get a directory listing of the directory where all the files are and check that the request parameter matches one of the entries. Although it's more work, this automatically defeats pretty much any weirdness that an attacker can attempt. (One comment.)
|
These are my WanderingThoughts GettingAround This is part of CSpace, and is written by ChrisSiebenmann. * * * Atom feeds are available; see the bottom of most pages. Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web |