nms-cgi-devel

[Nms-cgi-devel] Re: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are not rejected by the script

[Jonathan S. <jn...@ge...>]

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
> 
> When I read the readme to TFMail, I was pleased, to see the possibility not
> only to upload files to the E-Mail, but to limit the range of file types by
> its extension. But in fact file types other than "allowed" in the
> configfile, are NOT rejected, but only renamed to the last extension that is
> listed.
> 
> Expected behaviour:
> If someone tries to upload a file with an extension that is not listed in
> the configfile, he informed that he was to upload a file type that is not
> supported.
> 
> Existing behaviour:
> If someone uploads a file with an extension, which is not listed in the
> configfile, the attachment is sent with no further comment, but the file
> (extension) is renamed (and so "defect" for many users).
> 
> Does anyone knows how to get the "Expected behaviour"?
> 

You might expect that behaviour but the existing behaviour is the
advertised and designed behaviour.  The problem is that the 'extension'
of the file is not a guarantee of the file type: I could quite easily
rename some random file with a .doc suffix and upload it and the program
would be none the wiser.

Of course it might be nice to have something like this as an option, you
can change the TFmail.pl at line 649 where there is:

         if ( $filename =~ m#\.(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }
         elsif ( $ct =~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }

To

         if ( $filename =~ m#\.(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }
         elsif ( $ct =~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc $1} )
         {
            $bestext = $goodext{lc $1};
         }
	 elsif ( $treq->config('strict_extension','0') )
         {
	    die "Bad file type";
         }

and then add

   strict_extension: 1

to your .trc file which will do what you want.  I'm not sure if this is
exactly what we would put in a released version, so I am copying the
developers list to see if anyone has a better idea.

/J\
-- 

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are notrejected by the script

[Cole B. <col...@gm...>]

=20
Hello Mr. Stowe,

Thank you for your help. The changings to the script does indeed block
unwanted extensions. But the result is, that a simple "Application =
Error"
occurs. This mesage will not make it clear to the user, that a wrong =
file
type is responsible that for. To create a clear errorpage, I could =
extend
the debug info. But the developers say that debug is only f=FCr testing, =
not
for real life scenario. So is there a better way to do that? If it is to
much work to do it "quick n' dirty", is this feature planed to debut in
future versions of TFMail?

To be honest, I do not understand what was the developers intention on =
the
current "file type limitation" system. OK, executable files are renamed =
(if
not listed), which is good. For your example with the image it is well =
done.
But what if the upload is for "all" files exept executables? Then you =
have
to put hundreds of file extension to the list, just to block a couple...

Wishlist for future Versons of Tfmail:

- Possibility to configure if the File Extension list is a white or
blacklist
- Possibility to configure if wrong file types are rejected (with proper
errorpage) or renamed

Best Wishes, Claus Berghammer



-----Original Message-----
From: Jonathan Stowe
Sent: Tuesday, March 28, 2006 8:58 PM
To: colebantam
Cc: NMS-CGI-Support; NMS Devel
Subject: Re: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are
notrejected by the script

On Tue, 2006-03-28 at 17:16, Cole Bantam wrote:
> Hello there,
>=20
> When I read the readme to TFMail, I was pleased, to see the=20
> possibility not only to upload files to the E-Mail, but to limit the=20
> range of file types by its extension. But in fact file types other=20
> than "allowed" in the configfile, are NOT rejected, but only renamed=20
> to the last extension that is listed.
>=20
> Expected behaviour:
> If someone tries to upload a file with an extension that is not listed =

> in the configfile, he informed that he was to upload a file type that=20
> is not supported.
>=20
> Existing behaviour:
> If someone uploads a file with an extension, which is not listed in=20
> the configfile, the attachment is sent with no further comment, but=20
> the file
> (extension) is renamed (and so "defect" for many users).
>=20
> Does anyone knows how to get the "Expected behaviour"?
>=20

You might expect that behaviour but the existing behaviour is the =
advertised
and designed behaviour.  The problem is that the 'extension'
of the file is not a guarantee of the file type: I could quite easily =
rename
some random file with a .doc suffix and upload it and the program would =
be
none the wiser.

Of course it might be nice to have something like this as an option, you =
can
change the TFmail.pl at line 649 where there is:

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }

To

         if ( $filename =3D~ m#\.(\w{1,8})$# and exists $goodext{lc $1} =
)
         {
            $bestext =3D $goodext{lc $1};
         }
         elsif ( $ct =3D~ m#^[\w\-]+/(\w{1,8})$# and exists $goodext{lc =
$1} )
         {
            $bestext =3D $goodext{lc $1};
         }
	 elsif ( $treq->config('strict_extension','0') )
         {
	    die "Bad file type";
         }

and then add

   strict_extension: 1

to your .trc file which will do what you want.  I'm not sure if this is
exactly what we would put in a released version, so I am copying the
developers list to see if anyone has a better idea.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/

[Nms-cgi-devel] RE: [Nms-cgi-support] TFMail: Wrong Filetypes (extensions) are notrejected by the script

[Jonathan S. <jn...@ge...>]

On Thu, 2006-03-30 at 11:31, Cole Bantam wrote:
>  Hello Mr. Stowe,
>=20
> Thank you for your help. The changings to the script does indeed block
> unwanted extensions. But the result is, that a simple "Application Erro=
r"
> occurs. This mesage will not make it clear to the user, that a wrong fi=
le
> type is responsible that for. To create a clear errorpage, I could exte=
nd
> the debug info. But the developers say that debug is only f=C3=BCr test=
ing, not
> for real life scenario. So is there a better way to do that? If it is t=
o
> much work to do it "quick n' dirty", is this feature planed to debut in
> future versions of TFMail?
>=20

Yes correct that is all that it was intended to do.  The feature to use
a template for the error message is on the TODO.

> To be honest, I do not understand what was the developers intention on =
the
> current "file type limitation" system. OK, executable files are renamed=
 (if
> not listed), which is good. For your example with the image it is well =
done.
> But what if the upload is for "all" files exept executables? Then you h=
ave
> to put hundreds of file extension to the list, just to block a couple...
>=20
> Wishlist for future Versons of Tfmail:
>=20
> - Possibility to configure if the File Extension list is a white or
> blacklist
> - Possibility to configure if wrong file types are rejected (with prope=
r
> errorpage) or renamed

Code contributions are gratefully accepted.

/J\
--=20

This e-mail is sponsored by http://www.integration-house.com/