Closed (fixed)
Project:
Drupal core
Version:
5.0-rc1
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
26 Dec 2006 at 18:21 UTC
Updated:
11 Jan 2007 at 08:01 UTC
Jump to comment: Most recent
Now that the likely new package format for interface translations is separate smaller PO files in the module folders, it is important to protect these files from reading over HTTP. Since the PO files contain exact information about the version of the source files used to generate the originating translation template, they provide good tips to check for possible security problems on the site.
| Comment | File | Size | Author |
|---|---|---|---|
| Drupal.protect.po.files.patch.txt | 647 bytes | gábor hojtsy |
Comments
Comment #1
morbus iffSee also http://drupal.org/node/79018. -1.
Comment #2
gábor hojtsyMorbus how is that issue related? I have read through most of the counter points which could cause a -1.
- There is no point in hiding PO files because there are other ways to fingerprint the Drupal version anyway? Are there other ways to possibly fingerprint exact CVS revision numbers (which are directly stored in PO files)?
- We should not hide PO files, because the 'files' folder could have PO files in there? We can provide exceptional rules in the .htaccess there as stated in the issue you pointed to.
- There should not be PO files under the document root? I agree with this way of thinking but the current Drupal architecture dictates module files and all corresponding files to be under the document root, so we either try to safeguard this layout as much as possible or change it. It is not possible to change it in Drupal 5.
- What about PO files being indexed by search engines, if not hidden? Is this desired / not a problem? I think this is not desired, so we better hide them.
Comment #3
webernet commentedPlease do not RTBC your own patches.
Comment #4
ChrisKennedy commented@webernet: patches can be set to RTBC by oneself if they are sufficiently minor in scope; this is not a rare thing. In this case the patch is very simple, uses well-tested code, and was submitted by a longtime contributor, so there isn't much point in squabbling. If you would like to propose such a rule, I suggest emailing dev and/or posting on g.d.o. If you are concerned about this patch it would be better to verify the patch or argue on the merits rather than merely changing the status.
I think this patch is fine. I don't see any need to download .po files for 99% of drupal sites; .info is already restricted in the .htaccess and is comparable in its attributes.
Comment #5
drummStatus use arguments aren't too worthwhile at the moment. Lets concentrate on full reviews until Drupal 5 is out.
Comment #6
dries commentedThis may sound a bit radical, but can't we use whitelisting rather than blacklisting? The list of extensions is getting unwieldy. It might be easier to allow php, css, jpg, png, gif, ico and a couple of other file formats, and to have a wildcard for the files-directory ...
Comment #7
gábor hojtsyI am fine with whitelisting in case someone collects of list of valid file extensions used in contrib modules (like swf and such).
Comment #8
morbus iffNo, whitelisting would be difficult to pull off. We /know/ what is in OUR distribution, but not what files the user actually wants to use themselves under the root distribution. If we whitelist only jpg, gif, and png, we're unnecessarily blacklisting say, font files (.ttf and so forth for SIFR), TIFFs (native screenshot format of OS X) and any of a zillion other possibilities. We can't assume that our distribution directory will ONLY be used for Drupal related things.
Comment #9
Anonymous (not verified) commentedBut we would train the user on how to add his own list of extensions to the whitelist. If the file extension is common enough the user could request support or submit a patch. +1 whitelisting. +1 Gábor's patch.
Comment #10
morbus iffThat is far outside the realm of what we should be training our users, and is a "hidden cost" - users expect files they add to their root to be viewable. Likewise, installation of Drupal should not a) teach the user how to modify or customize their webserver, b) modify their FTP client to show hidden files (dotfiles are normally hidden).
Comment #11
drummCommitted to HEAD. I think these three characters are certainly okay for 5.0.
Whitelisting can be discussed for 6.0 or later. And its .htaccess, the thing shouldn't be expected to work half the time anyway, so don't spend too much time on it.
Comment #12
(not verified) commented