Re: [SM-DEVEL] SF.net SVN: squirrelmail:[13777] branches/SM-1_4-STABLE/squirrelmail

[Jonathan A. <jo...@sq...>]

On Tue, 2 Jun 2009 08:52:36 +0200, Thijs Kinkhorst
<ki...@sq...> wrote:

>On tiisdei 2 Juny 2009, Jonathan Angliss wrote:
>> >@@ -2,4 +2,5 @@
>> > Deny from All
>> > Allow from 127
>> > Allow from 10
>> >-Allow from 192
>> >+Allow from 172.16
>> >+Allow from 192.168
>
>This is still not a complete specification of RFC 1918 addresses, although it 
>doesn't include publically routable ones anymore. I've updated it now to be 
>consistent with RFC 1918.

I noticed, thanks for updating.

>> Currently we point the web root to the base of the SquirrelMail
>> directory, instead of the src/ directory.  Currently that's because
>> plugins reside in the plugins/ folder, and may require some output.
>> The user that jumped on IRC questioned why so many PHP scripts can be
>> executed without a need to.  Whilst I generally agree that the idea is
>> that you should be able to just drop and run SquirrelMail without
>> having to tinker with any paths, I sometimes wonder how difficult it'd
>> be making all the subdirectories outside the web root.  I also
>> question whether this is one of those cases of "security by
>> obscurity", but it does lead to improve security in that some scripts
>
>I don't think it is - blocking access to things you don't need access to in 
>the first place is not obscurity but just sensible. It's obscurity if you can 
>in fact access it but it's made a bit more difficult to find out.

Files are still there, accessing them just became less than trivial,
ie you'd have to load them from some other script method, instead of
direct access.  I still believe this is to be a form of "security
through obscurity", ie you're not fixing potential issues, you're just
making them harder to get to.

>> that don't need to be executed by the user, should not be executable.
>> The example provided by the user on IRC was the themes folder.  Whilst
>> they're harmless, they can be executed as a script, and it only takes
>> small typos to introduce bugs.
>>
>> We only provide a limited number .htaccess files in the directories,
>> should we consider expanding it, as well as increasing the options
>> included (no listings and such)?  Do we want to consider the idea of
>> bumping stuff outside the web root?
>
>It would be altogether better if it would be possible to set the web root to 
>say the src/ dir and make all of our other scripts unreachable. However, we 
>cannot easily incorporate that into the current layout. There's the following 
>problems:
>* Plugins may ship pages that need to be accessed in an URL directly;
>* images are outside of src/
>* We do assumptions on the fact that you can link to say 'src/login.php' or
>  similar, or make path calculations based on that.
>
>Those are solvable but that would be strictly devel-only, because it means we 
>need to break the way plugins currently function.

We've done that already with the templates and such ;)  But it then
leads to an inability to just "drop and run" that most people are used
to, and in some cases are dependent on, for example those on web farms
ran by other people so they have no access to the httpd
configurations.

>One solution may be that we keep the current plugins dir where it is, and 
>forbid the supplying of functionality as a separate page. Instead, plugins 
>can provide a function to some kind of new (?) hook that allows that specific 
>functionality to be called from a script under src/.
>
>The images dir can just be moved. The assumptions made on URLs can probably be 
>resolved within our code itself, although it might take a non-trivial amount 
>of refactoring.

That's what I thought, quite a large task.  For a quick fix however,
we can do the same as what has been done for the config/ folder for
example, and just explicitly deny access to some/most folders.  This
is only a fix for those that are running a system that supports
.htaccess files, *and* allows the local files to be used.  We could
probably document all the other methods of protecting the directories
however.

-- 
Jonathan Angliss
<jo...@sq...>