Support

Thank you! I've been saying that forever and even wrote a lengthy blog post about it which I see you've read and commented on :) Everything you said is perfectly correct. If you just turn off directory indexes you are doing the same thing as index.html files, only much better. If you're using my master .htaccess or Admin Tools Professional's .htaccess Maker you actually completely block the access to the sensitive directories, so the existence of index.html files or having directory indexes turned off is completely inconsequential. Even if a PHP file is vulnerable, it will be inaccessible from the web, therefore not an attack vector any more.

Yet, JED is adamant in abiding by this stupid, outdated rule which serves no security purpose. Adding insult to injury, they still consider it a "security feature" and will reject extensions violating that rule as "insecure". Insecure my... well, you get it :)

It's hardly a no-brainer if you are a commercial host. Some of your clients may want this behavior to host a download area. But I agree that if you have a site based on any CMS (even a home brew one) directory indices should be turned off.

Well, the Joomla! team is a very loose term :) I have provided bug fix and feature patches to Joomla!, so that makes me part of the team, I guess (my name is in the JoomlaCode.org project listing of the Joomla! CMS anyways). What needs be done here is a decision among the people with commit access regarding what purpose the .htaccess should serve. Is it there for SEF only or does it serve a higher security purpose? In the latter case, most of my Master .htaccess should be included in it.

But this poses another issue. For years, there has been no "best practices" official document. Developers don't realise that media files which must be used by both the front and the back-end belong to the /media folder, NOT the administrator folder. They don't realise that everything MUST pass though Joomla!'s index.php files unless you're modifying the core Joomla! database or core Joomla! files (and there's only a handful of software which is supposed to do that). Nobody understands that the contents of the cache directory MUST NOT be accessed over the web. Several misconceptions which are in widespread use today and diminish our sites' security happened because nobody cared explaining Joomla! 1.5's directory structure to developers. Unfortunately, this means that if something close to my Master .htaccess was included in the core, a big portion of the JED-listed extensions would not work any more. Yup, it's Catch-22.

Regarding the "security through obscurity", I'm not entirely opposed to it. Sometimes it serves a good purpose. It's another thing, however, to insist that it is the ONLY security rule you should follow. I mean, JED gives a false sense of security to its users. Just because some software is JED-listed it doesn't mean it's secure. What if the developer did include index.html files but has a ton of potential SQLi and XSS vulnerabilities all over his gosh darn code? I've seen quite a few such extensions, but I can't report them. I have to create an exploit, notify the developer, wait for 15 days to see if he releases a fix, if he doesn't I have to publish the exploit and notify VEL which will notify JED which will delist the extension and notify the developer. And, yet, JED users believe that if an extensions is listed in JED it's secure. Big pile of cow droppings...

In any way, you can safely remove all index.html files. If you have SSH access you can go to your site's root and do something like:
find . -type f -name index.html -delete
You'll see a few hundreds to a few thousands of files being removed - and a backup which is 15% smaller. Woot! :)

As for developers, I'd first like 'em to think about basic security stuff when they're coding their extensions and then talk about index.html files. And some of 'em should really open up their bloody ears and listen. A particular developer of a popular extension has been contacted by at least a dozen of my users and notified that he's accessing files in the administrator directory from the front-end. He replied once and he simply said "that's how we did it, take it or leave it". Can you believe that? The guy is mixing up the contents of the two separate Joomla! applications (front- and back-end) and he feels very proud that he does that. Huh! So, no, I don't think that a rebellion against the JED rule is what we need. What we need is a rebellion against developers who refuse to fix security-related issues in their software.

OK, my rant is over :)

Just a clarification: the 15 days waiting period is not imposed by JED, it's a self-imposed rule by responsible security consultants. When you discover an unpublished vulnerability, you have to let the developer fix it. If there is a published vulnerability reported to VEL, the developer is notified immediately and the JED listing is taken down within a few hours, which is pretty cool. My point is not that JED reacts slowly to security issues, but that it doesn't and can't guarantee the security of extensions published in it. It's not JED's job to be a code auditor and users should not assume that. It's a directory. As such, it should only concern itself with the following: a. does an extension install? b. is it compatible with Joomla!'s own license c. is it really compatible with the exact Joomla! versions it says it is? And that's about it.

Regarding 1.7's updater, it's a little rough on the edges still, but slowly getting "there". Give it some time. It took me 6 months to get my own updater run smooth as silk - and I released an update every month to get there! Updaters are tricky and J!'s updater is still very young.

Regarding the removal of index.html files, there's no speed penalty if they exist. They are not used. The problem is when you're installing an extension and one fifth of the files installed could be skipped. This could make the difference between an extension which installs on a slow shared host using the FTP layer and one which doesn't. The extension discovery in J! 1.6/1.7 was made to work around that, but for the majority of cases it just sounds to me like shooting mosquitos with a canon - it's an overkill. Let alone the fact that Joe Average doesn't understand how to manually unpack an extension before getting to a point he can run the extension discovery feature.