2007-05-24
Firefox preferences settings that I use
In the spirit of my Firefox extensions, and since I
just went through this exercise today, here are the Firefox preferences
customizations that I currently use. At least some of these are only
present in relatively bleeding edge Firefox builds, and you will need
to use about:config to enable at least some of them.
(I have not put everything in here, just the stuff that I always forget and that irritates me when it's missing.)
| browser. backspace_action | 1 | Scroll the page up on backspace. This matches the traditional
Unix behavior of Netscape 4, which I am very very used to by now. (This is only present in recent Firefox builds; before that Backspace always went back in the history. As a result, my own personal Firefox build has this chainsawed out via more direct methods.) |
| browser. blink_allowed | false | I do not want <blink> to do anything. |
| browser. download. manager. retention | 0 | 'Do not remember my downloads', ie 'do not clutter the download dialog with stuff I have already deleted'. I always have to remember that this setting is in the Privacy section of Preferences, unlike the other download settings. |
| browser. enable_automatic_image_resizing | false | I do not want my images to be resized into illegibility in order to fit in my current browser window, thanks. |
| browser. formfill. enable | false | Also in the Privacy settings, although I consider it to be another 'do not annoy me thanks bye' setting. |
| browser. send_pings | false | See here for an explanation. |
| browser. urlbar. matchOnlyTyped | true | Ideally I would be able to turn off URL bar autocompletion entirely; however, this does not seem possible in current Firefox builds. Making it only autocomplete things I've explicitly entered into the URL bar is the best I can do. |
| extensions. checkCompatibility | false | This is necessary to install several of my Firefox extensions in current Firefox trunk builds, even with the Nightly Tester Tools installed. |
In general, the MozillaZine Knowledge Base has a very large set of pages giving lots of information about Firefox preferences; you can start here and then follow their links.
2007-05-23
The danger of a web server writeable document area
Once you have CGI programs running through your web server, you might rationally ask why allowing them to write into the web server's document area adds any extra danger: after all, if a CGI program is compromised, the attacker gets to run all the code they want anyways.
Well, in theory. The flaw in this theory is that there are different kinds of vulnerabilities.
In practice it turns out that 'file dropper' vulnerabilities, where a CGI program (especially PHP programs) can be tricked into writing attacker-supplied files to an attacker-supplied location, are much more common than code execution vulnerabilities, where an attacker can make your CGI actually run their code. In a sense, this shouldn't be too surprising; many CGI programs already write files and thus just need to be tricked about where to put them and what to put in them, but few dynamically execute code to start with.
(Dynamic code execution gets most of the press anyways for various reasons, including that it is the most dangerous sort of vulnerability.)
If you have a file dropper exploit and can write to some place where the files will be executed, you can bootstrap to running your own code; the classical case is to drop PHP files into the document area of a web server that runs PHP. Nor are you entirely safe with a static file document area; planting HTML files is enough to infect your web site with spam pages and attempts to exploit browser vulnerabilities, both of which can be lucrative activities.
And even if an attacker has fully compromised a CGI program, they may
want to stick their own program into your web server setup so that they
can hide better. Often exploiting the CGI's vulnerability may leave very
odd log messages that you might notice in time, whereas with their own
crafted program the cracker can just send bland looking POST requests
and you'll never be the wiser.
(For example, something we saw here dropped a Bzip.php file into a directory that already had legitimate Tar.php and Zip.php files. The meticulous will notice this anyways, but more casual people could overlook it for some time.)
2007-05-22
A case for breaking the web server ownership guidelines
I have to admit that there actually is a reason to break the good practice for webserver file ownership: the 404 handler trick for lightweight caching of semi-dynamic websites.
The 404 handler trick comes from three observations:
- most dynamic websites are in practice not very dynamic; the actual pages served change rarely.
- Apache (and other web servers) are many times faster at serving static content than dynamic content.
- Apache (and etc) can let you take arbitrary actions on 'page missing' errors.
So the 404 handler trick is to make your dynamic website run as Apache's page missing handler. Once you've checked that the URL is a real page and generated the page's content, you write it into the static document area as well as returning it to the user; the next time around Apache will just serve it directly. And if something changes that means you need to regenerate the page, you just delete the page from the static document area and the next time it's accessed it'll get rebuilt automatically.
(Disclaimer: I didn't invent this. I believe I got it from Sam Ruby, but the practice is widespread.)
However, this requires that your 404 handler be running as a user that can write into some part of the document area, so that it can actually write out those static files for Apache to serve. You can make this less dangerous by restricting Apache to only serve static files (no PHP and so on) from that area, although this may be tricky.
(Note: less dangerous, not safe. There are some dangers even with just static files, but a discussion of the issue doesn't fit into this margin.)
2007-05-09
CSS separates layout from content less than you'd like
It is generally an article of faith that once you switch to (properly done) CSS, you can do significant layout changes without having to change your content. Unfortunately I believe that this is somewhat of a myth in practice.
In practice, what you can do with CSS alone is limited to how your content is structured and tagged with things like CSS classes and ids. And the problem is that generally, people do not obsessively structure and tag their content; they mark it up and tag it for what their CSS currently needs, with a side helping of tagging for changes they think they might want to make in the future.
(This shouldn't surprise anyone, since people strongly resist doing extra work that seems (at the time) unlikely to ever be used. In fact, obsessively creating tagged markup that you don't see a need for is really a case of premature optimization.)
Thus on most sites there are fairly strong limits on what can be done with CSS changes alone; going beyond this needs some content changes. If you're in luck, all you need is for existing structures to be tagged so you can yank them around. If you're unlucky, you need structural changes that add new <div>s or <span>s.
In other words, what you get from CSS in practice is that it is easier to make layout changes that you were already thinking about (and thus built hooks for into your content). This is not a bad thing, but it is far from the panacea that common CSS folklore makes it out to be.
(The way to test this is not to look at example sites, but to get something like Stylish and wander around trying to make changes to random sites with CSS-based layouts.)