Why change inc to php?

I updated today and found all languages changed from *.inc
to *.php

As a general rule, I think inc is better from a security
standpoint
as it avoids funny tricks with specially crafted urls. The
specific
case is probably harmless as the files only contain
assignments to
$lang, but I still wonder why...


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

Hi,

This particular change was made to avoid the nasty security
problem
whereby a user could directly browse to the .inc files and
read the
contents!  WebSVN didn't come with any security mesures to
avoid this
problem.  Renaming to .php solves the issue without any
other fuss.

Tim

On 03/06/07, Alessandro Vesely <veselytana.it> wrote:
> I updated today and found all languages changed from
*.inc to *.php
>
> As a general rule, I think inc is better from a
security standpoint
> as it avoids funny tricks with specially crafted urls.
The specific
> case is probably harmless as the files only contain
assignments to
> $lang, but I still wonder why...
>
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
> For additional commands, e-mail: dev-helpwebsvn.tigris.org
>
>


-- 
http://www.timothyarmes.c
om

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

On Sunday 03 June 2007 20:10, Timothy Armes wrote:
> On 03/06/07, Alessandro Vesely <veselytana.it> wrote:
> > I updated today and found all languages changed
from *.inc to *.php
> >
> > As a general rule, I think inc is better from a
security standpoint
> > as it avoids funny tricks with specially crafted
urls. The specific
> > case is probably harmless as the files only
contain assignments to
> > $lang, but I still wonder why...
>
> This particular change was made to avoid the nasty
security problem
> whereby a user could directly browse to the .inc files
and read the
> contents!  WebSVN didn't come with any security mesures
to avoid this
> problem.  Renaming to .php solves the issue without any
other fuss.

I believe that the best solution is to put all files that
are not supposed to 
be requested by the user in a directory *outside* the
document root. I.e. 
instead of this:

/usr/share/websvn
+-index.php
+-wsvn.php
+-templates
+-include

you get

/usr/share/websvn
+-public
| +-index.php
| +-wsvn.php
| +-templates
+-include

Then point svn.example.com or www.example.com/websvn 
to /usr/share/websvn/public instead of /usr/share/websvn and

add /usr/share/websvn/include to PHP's include path.

-- 
Magnus Holmgren        holmgrenlysator.liu.se
                       (No Cc of list mail needed, thanks)

  "Exim is better at being younger, whereas sendmail is
better for 
   Scrabble (50 point bonus for clearing your rack)" --
Dave Evans

You're totally right, putting all include files out of a
webserver 
accessible directory would be the best solution. But this
would also 
complicate the installation process.

An other approach would be to protect the include files,
i.e. with a 
constant, that is only set in files, which are intended to
be requested 
directly and a check for this constant in all included
files. If it is 
not set, just exit, since it must be an unintended
execution.
As far as i remember, there are some tools out there using
this 
mechanism. Was it phpMyAdmin? I'm not sure...

Magnus Holmgren schrieb:
> On Sunday 03 June 2007 20:10, Timothy Armes wrote:
>> On 03/06/07, Alessandro Vesely <veselytana.it> wrote:
>>> I updated today and found all languages changed
from *.inc to *.php
>>>
>>> As a general rule, I think inc is better from a
security standpoint
>>> as it avoids funny tricks with specially
crafted urls. The specific
>>> case is probably harmless as the files only
contain assignments to
>>> $lang, but I still wonder why...
>> This particular change was made to avoid the nasty
security problem
>> whereby a user could directly browse to the .inc
files and read the
>> contents!  WebSVN didn't come with any security
mesures to avoid this
>> problem.  Renaming to .php solves the issue without
any other fuss.
> 
> I believe that the best solution is to put all files
that are not supposed to 
> be requested by the user in a directory *outside* the
document root. I.e. 
> instead of this:
> 
> /usr/share/websvn
> +-index.php
> +-wsvn.php
> +-templates
> +-include
> 
> you get
> 
> /usr/share/websvn
> +-public
> | +-index.php
> | +-wsvn.php
> | +-templates
> +-include
> 
> Then point svn.example.com or www.example.com/websvn 
> to /usr/share/websvn/public instead of
/usr/share/websvn and 
> add /usr/share/websvn/include to PHP's include path.

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

Sebastian Petters / 4wd media wrote:
> 
> An other approach would be to protect the include
files, i.e. with a
> constant, that is only set in files, which are intended
to be requested
> directly and a check for this constant in all included
files. If it is
> not set, just exit, since it must be an unintended
execution.

Malicious users can still call
http://svn.example.com/include/that_file.php
?required_constant=value


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

Timothy Armes wrote:
> Hi,
> 
> This particular change was made to avoid the nasty
security problem
> whereby a user could directly browse to the .inc files
and read the
> contents!

Apache users should have configured how to serve .inc
files.
Their content can be read in the WebSVN repository anyway.

> WebSVN didn't come with any security mesures to avoid
this
> problem.  Renaming to .php solves the issue without any
other fuss.

I see.

Thank you for replying.
Ale

> Tim
> 
> On 03/06/07, Alessandro Vesely <veselytana.it> wrote:
>> I updated today and found all languages changed
from *.inc to *.php
>>
>> As a general rule, I think inc is better from a
security standpoint
>> as it avoids funny tricks with specially crafted
urls. The specific
>> case is probably harmless as the files only contain
assignments to
>> $lang, but I still wonder why...


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

>> An other approach would be to protect the include
files, i.e. with a
>> constant, that is only set in files, which are
intended to be requested
>> directly and a check for this constant in all
included files. If it is
>> not set, just exit, since it must be an unintended
execution.
> 
> Malicious users can still call
> http://svn.example.com/include/that_file.php
?required_constant=value
> 

Hi Alessandro!

This would only be possible with variables (and
register_globals 
enabled), but as far as i know, there is no way to define a
constant 
from the outside of a script. The main files could contain
something 
like this:

define('WEBSVN_INCLUSION_PROTECTION', 1);

The include files could check for this constant:

if (!defined('WEBSVN_INCLUSION_PROTECTION')) exit(1);

Sebastian

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org

Hi all,

In my oppinion the best solution would be - as earlier
mentioned -
to move away all non directly called .php/.inc files to a
location
not in DocumentRoot.

Greets
Sven

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribewebsvn.tigris.org
For additional commands, e-mail: dev-helpwebsvn.tigris.org