« Return to Thread: Re: SF.net SVN: squirrelmail:[13777] branches/SM-1_4-STABLE/squirrelmail
Re: SF.net SVN: squirrelmail:[13777] branches/SM-1_4-STABLE/squirre
by Thijs Kinkhorst
::
Rate this Message:
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.
> 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 scriptsI 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.
> 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.
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.
cheers,
Thijs
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> >@@ -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.
> 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
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.
> 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.
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.
cheers,
Thijs
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@...
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
signature.asc (500 bytes) « Return to Thread: Re: SF.net SVN: squirrelmail:[13777] branches/SM-1_4-STABLE/squirrelmail
| Free embeddable forum powered by Nabble | Forum Help |
